SQL Index Fragmentation Test

Fragmentation exists when indexes have pages in which the logical ordering, based on the key value, does not match the physical ordering inside the data file. All leaf pages of an index contain pointers to the next and the previous pages in the index. This forms a doubly linked list of all index/data pages. Ideally, the physical order of the pages in the data file should match the logical ordering. Overall disk throughput is increased significantly when the physical ordering matches the logical ordering of the data. This leads to much better performance for certain types of queries. When the physical ordering does not match the logical ordering, disk throughput can become less efficient, because the disk head must move back and forth to gather the index pages instead of scanning forward in one direction. This is how fragmentation affects I/O performance.

The first step to resolving the performance threat posed by fragmented indexes is to identify which indexes are fragmented. The SQL Index Fragmentation test helps in this regard. This test scans the indexes on a Microsoft SQL server 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 defragment/rebuild the affected indexes, so as to increase disk throughput and improve overall SQL performance.

This test has been disabled by default. To enable this test, go to the enable / disable tests page using the menu sequence : Agents -> Tests -> Enable/Disable, pick Microsoft SQL as the Component type, Performance as the Test type, choose this 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 : A Microsoft SQL server

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 IP address of the Microsoft SQL server.
  3. Port - The port number through which the Microsoft SQL server communicates. The default port is 1433.
  4. ssl – If the Microsoft SQL server being monitored is an SSL-enabled server, then set the ssl flag to Yes. If not, then set the ssl flag to No.
  5. instance - In this text box, enter the name of a specific Microsoft SQL instance that is to be monitored. The default value of this parameter is “default”. To monitor a Microsoft SQL instance named “CFS”, enter this as the value of the INSTANCE parameter.
  6. USER – If a Microsoft SQL Server 7.0/2000 is monitored, then provide the name of a SQL user with the Sysadmin role in this text box. While monitoring a Microsoft SQL Server 2005 or above, provide the name of a SQL user with all of the privileges outlined in User Privileges Required for Monitoring Microsoft SQL server.

  7. password - The password of the specified user
  8. confirm password - Confirm the password by retyping it.
  9. domain - By default, none is displayed in the DOMAIN text box. If the ‘SQL server and Windows’ authentication has been enabled for the server being monitored, then the DOMAIN can continue to be none. On the other hand, if ‘Windows only’ authentication has been enabled, then, in the DOMAIN text box, specify the Windows domain in which the managed Microsoft SQL server exists. Also, in such a case, the USER name and PASSWORD that you provide should be that of a user authorized to access the monitored SQL server.
  10. isntlmv2 - In some Windows networks, NTLM (NT LAN Manager) may be enabled. NTLM is a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users. NTLM version 2 (“NTLMv2”) was concocted to address the security issues present in NTLM. By default, the isntlmv2 flag is set to No, indicating that NTLMv2 is not enabled by default on the target Microsoft SQL host. Set this flag to Yes if NTLMv2 is enabled on the target host.
  11. ISPASSIVE – If the value chosen is yes, then the Microsoft SQL server under consideration is a passive server in a SQL 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.
  12. 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 aschema, 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.*.
  13. query time out - Specify the time period up to which a query has to wait to obtain the required result set from the database in the QUERY TIME OUT 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. 
  14. min high fragment limit - Provide the limit (in percentage) of fragmentation above which an index is termed as a highly fragmented index in the min HIGH FRAGMENT LIMIT text box. By default, the value specified here is 30. This means that if 30% or more of a monitored index is found to be fragmented, then such indexes are counted as highly fragmented indexes.
  15. min very high fragment limit - Provide the limit (in percentage) of fragmentation above which an index is termed as a very highly fragmented index in the MIN VERY HIGH FRAGMENT LIMIT text box. By default, the value specified here is 50. This means that if 50% or more of a monitored index is found to be fragmented, then such indexes are counted as very highly fragmented indexes.
  16. DETAILED DIAGNOSIS – To make diagnosis more efficient and accurate, the eG Enterprise 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 SQL indexes:

Indicates the number of highly fragmented indexes.

Number

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. High levels of fragmentation 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.

Once the affected indexes are isolated, take the necessary steps to correct the fragmentation. Towards this end, SQL provides the following statements:

  1. DROP INDEX followed by CREATE INDEX
  2. CREATE INDEX WITH DROP_EXISTING
  3. ALTER INDEX ... REORGANIZE
  4. ALTER INDEX ... REBUILD

Very highly fragmented SQL indexes:

Indicates the number of indexes that are very highly fragmented.

Number

If over 50% 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. High levels of fragmentation 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.

Once the affected indexes are isolated, take the necessary steps to correct the fragmentation. Towards this end, SQL provides the following statements:

  1. DROP INDEX followed by CREATE INDEX
  2. CREATE INDEX WITH DROP_EXISTING
  3. ALTER INDEX ... REORGANIZE
  4. ALTER INDEX ... REBUILD