Oracle RAC Index Fragmentation Test

Indexes are Oracle database objects that provide a fast, efficient method of retrieving data from database tables. The physical addresses of required rows can be retrieved from indexes much more efficiently than by reading the entire table. Effective indexing usually results in significant improvements to SQL performance.

Oracle’s default index structure is B*-tree, which stands for “Balanced tree.” It has a hierarchical tree structure. At the top is the header. This block contains pointers to the appropriate branch block for any given range of key values. The branch block points either to another branch block, if the index is big, or to an appropriate leaf block. Finally, the leaf block contains a list of key values and physical addresses (ROWIDs) of rows in the database. Theoretically, any row in a table, even a big one, could be retrieved in a maximum of three or four I/Os (input/output operations): one header block, one or two branch block(s), and one leaf block.

The advantages of indexing do not come without a cost. As database objects, indexes are created for tables only and they must be in sync with them: indexes must be updated by the database with every data manipulation language (q) operation - INSERT, DELETE, or UPDATE. Where there are a large number of tables with dynamic data, too many INSERTs, DELETEs, and UPDATEs on the tables can over time, fragment the index. When indexes are fragmented, queries take longer to pull out rows from tables, thereby significantly increasing disk I/O. This adversely impacts overall SQL performance.

The first step to resolving the performance threat posed by fragmented indexes is to identify which indexes are fragmented. The Oracle RAC Index Fragmentation test helps in this regard. This test scans a pre-configured index sample for high and very high levels of fragmentation, and reports the count of fragmented indexes. Using the detailed diagnosis capability of the test, you can also quickly drill down to the specific indexes that have been fragmented. You can thus proceed to rebuild the fragmented indexes to reduce disk I/O. 

This test is disabled by default. To enable the test, go to the enable / disable tests page using the menu sequence : Agents -> Tests -> Enable/Disable, pick the Oracle Cluster as the desired Component type, set Performance as the Test type, choose the test from the disabled tests list, and click on the >> button to move the test to the ENABLED TESTS list. Finally, click the Update button.

Target of the test : Oracle Cluster

Agent deploying the test : An internal agent

Outputs of the test : One set of results for every DisplayName configured for the object name parameter of this test

Configurable parameters for the test
  1. TEST PERIOD - How often should the test be executed
  2. Host – The host for which the test is to be configured
  3. Port - The port on which the server is listening
  4. orasid - The variable name of the oracle instance

  5. service name - A ServiceName exists for the entire Oracle RAC system. When clients connect to an Oracle cluster using the ServiceName, then the cluster routes the request to any available database instance in the cluster. By default, the service name is set to none. In this case, the test connects to the cluster using the orasid and pulls out the metrics from that database instance which corresponds to that orasid. If a valid service name is specified instead, then, the test will connect to the cluster using that service name, and will be able to pull out metrics from any available database instance in the cluster.

    To know the ServiceName of a cluster, execute the following query on any node in the target cluster:

    select name, value from v$parameter where name =’service_names’

  6. User – In order to monitor an Oracle RAC, a special database user account has to be User – In order to monitor an Oracle database server, a special database user account has to be created in every Oracle database instance that requires monitoring. A Click here hyperlink is available in the test configuration page, using which a new oracle database user can be created. Alternatively, you can manually create the special database user. When doing so, ensure that this user is vested with the select_catalog_role and create session privileges.

    The sample script we recommend for user creation (in Oracle database server versions before 12c) for eG monitoring is:

    create user oraeg identified by oraeg create role oratest;

    grant create session to oratest;

    grant select_catalog_role to oratest;

    grant oratest to oraeg;

    The sample script we recommend for user creation (in Oracle database server 12c) for eG monitoring is:

    alter session set container=<Oracle_service_name>;

    create user <user_name>identified by <user_password> container=current default tablespace <name_of_default_tablespace> temporary tablespace <name_of_temporary_tablespace>;

    Grant create session to <user_name>;                                 

    Grant select_catalog_role to <user_name>;

    The name of this user has to be specified here.

  7. Password – Password of the specified database user
  8. Confirm password – Confirm the password by retyping it here.
  9. ISPASSIVE – If the value chosen is yes, then the Oracle server under consideration is a passive server in an Oracle cluster. No alerts will be generated if the server is not running. Measures will be reported as "Not applicable" by the agent if the server is not up.

  10. object name - Specify a comma-separated list of tables, the indexes of which need to be checked for fragmentation. Every table name should be specified in the following format: <DisplayName>:<schema_name>.<table_name>, where schema_name refers to the name of the table owner, and table_name refers to the name of the table. The DisplayName in your specification will appear as the descriptor of this test. For instance, to monitor the indexes of the alarm and history tables owned by user admin, your specification would be: AlarmMon1:admin.alarm,AlarmMon2:admin.history. To monitor all tables in a schema, the specification would be of the following format: <DisplayName>:<schema_name>.*. For example, to monitor all the tables in the admin schema, your specification would be: AlarmMon:admin.*.  

    You can also configure the object name to indicate what percentage of records in a table are to be considered by this test for running index fragmentation checks. To achieve this, your object name specification should be of the following format:  <DisplayName>:<schema_name>.<table_name>@<Percentage_of_records_in_the table>. For instance, say that you want to configure this test to monitor the indexes that correspond to 20% of the alarm table and 30% of the history table. The object name specification in this case will be: AlarmMon:admin.alarm@20,AlarmMon1:admin.history@30. It is recommended that you keep this ‘percentage value’ small, as higher values will make this test that much more resource-intensive.

    Note:

    Make sure that you configure the object name parameter with only table names and not view names. This is because, indexes are available for tables alone and not views.

  11. querytimeout - Specify the time period upto which a query has to wait to obtain the required result set from the database in the QUERYTIMEOUT text box. If the query is not successful or if the query waits for a time period exceeding the specified time limit, the test will automatically kill the query.

  12. To make diagnosis more efficient and accurate, the eG Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

    The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

    • The eG manager license should allow the detailed diagnosis capability
    • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Highly fragmented Oracle indexes:

Indicates the number of highly fragmented indexes.

 

 

If 30% - 49%  of an index is found to be fragmented, then such an index is counted as a highly fragmented index.

Ideally, the value of this measure should be 0. A high value indicates high index fragmentation. Fragmentation is characterized by splitting and spawning. Splitting happens when an index node becomes full with keys and a new index node is created at the same level as a full node. This widens the B*-tree horizontally.

Spawning is the process of adding a new level to an index. As a new index is populated, it begins life as a single-level index. As keys are added, a spawning takes place and the first-level node reconfigures itself to have pointers to lower-level nodes.

Both these phenomenon are key performance degraders. This is why, a high value of this measure, if left unchecked, can cause disk I/O to mount, queries to run for long periods, and the overall performance of the database server to deteriorate.

Use the detailed diagnosis of this measure to identify highly fragmented indexes, and proceed to rebuild them.

Very highly fragmented Oracle indexes:

Indicates the number of indexes that are very highly fragmented.

Number

If 50% or more of an index is found to be fragmented, then such an index is counted as a very highly fragmented index.

Ideally, the value of this measure should be 0. A high value indicates very high index fragmentation. Fragmentation is characterized by splitting and spawning. Splitting happens when an index node becomes full with keys and a new index node is created at the same level as a full node. This widens the B*-tree horizontally.

Spawning is the process of adding a new level to an index. As a new index is populated, it begins life as a single-level index. As keys are added, a spawning takes place and the first-level node reconfigures itself to have pointers to lower-level nodes.

Both these phenomenon are key performance degraders. This is why, a high value of this measure, if left unchecked, can cause disk I/O to mount, queries to run for long periods, and all performance of the database server to deteriorate.

Use the detailed diagnosis of this measure to identify very highly fragmented indexes, and proceed to rebuild them.