IBM Tivoli Netcool/OMNIbus Version 8.1

Indexing guidelines

Indexing can affect the performance of your SQL queries. Without indexing, a full database table scan is typically performed when an SQL query runs. Use indexing to limit the number of rows that are examined.

Tivoli Netcool/OMNIbus supports hash and tree index structures. The hash index supports equality comparisons in SQL queries. The tree index is an ordered index that stores column values in a sorted structure, and allows a wider range of comparisons, including equality, in SQL queries. Consequently, a tree index can be used in range queries and in queries with an ORDER BY clause.

Indexes are rebuilt whenever the ObjectServer is restarted, and these indexes use up a small amount of memory rather than physical disk space.

You can create indexes on all ObjectServer tables except the tables in the system databases, such as the catalog and security databases. Tivoli Netcool/OMNIbus also supports the use of indexes by sub-select clauses in SQL queries.

Although there is no limit on the number of indexes that you can create on a table, you must use indexes sparingly. Indexes incur a performance overhead because they are updated when insert, update, or delete operations are performed on the table on which they are based. For tables such as alerts.status, which are updated frequently, creating a large number of indexes can adversely affect the overall performance of the ObjectServer. Evaluate the tradeoff between indexing for fast retrieval of data and the performance degradation during insert, update, and delete operations.

Avoid indexing tables that contain only small amounts of data. Also avoid indexing columns that contain data values which frequently change.

The following columns are considered good candidates for indexing:
  • Columns that are searched or sorted against frequently; that is, columns typically used in ORDER BY clauses
  • Columns that are frequently used in WHERE clauses that contain the predicate formats supported for indexing; see Table 1
  • Columns with data that contains few duplicate values

Columns that are defined as primary keys are, by default, uniquely indexed. These special, implicit indexes are not stored in the catalog.indexes table. The Serial column in the alerts.status table is indexed by default.

Indexing restrictions on columns are as follows:
  • Only one index per column is allowed.
  • A column that is defined as Boolean cannot have a tree index.

During SQL processing, both the restriction filter for the table and the WHERE clause in each SELECT, UPDATE, DELETE, FOR EACH ROW, and EVALUATE statement is examined to determine whether an index scan should be performed instead of a full table scan. An index scan is performed when one or more predicates fulfills the following conditions:

The following table summarizes which predicate formats are supported for hash and tree indexes.
Table 1. Predicate formats for hash and tree indexes
Predicate format Hash index Tree index
ColumnName = ConstantExpression Yes Yes
ColumnName < ConstantExpression No Yes
ColumnName > ConstantExpression No Yes
ColumnName <= ConstantExpression No Yes
ColumnName >= ConstantExpression No Yes
ColumnName %= ConstantExpression

ColumnName %< ConstantExpression

ColumnName %> ConstantExpression

ColumnName %<= ConstantExpression

ColumnName %>= ConstantExpression

No No


Library | Support |