Azure 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 Azure SQL Index Fragmentation test helps in this regard. This test scans the indexes on the target Azure SQL database 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.
Target of the test : A Microsoft Azure SQL database
Agent deploying the test : A remote agent
Outputs of the test : One set of results for every DisplayName configured for the object name parameter of this test
| Parameters | Description |
|---|---|
|
Test Period |
How often should the test be executed. |
|
Host |
The host for which the test is to be configured. |
|
Port |
The port at which the specified Host listens. |
|
Database Name |
Specify the name of the Azure SQL database that is to be monitored. |
|
User Name and Password |
Against the User Name and Password parameters, specify the credentials of the user who is vested with DBOWNER rights to the configured Database Name. |
|
Confirm Password |
Confirm the specified Password by retyping it here. |
|
SSL |
If the Azure SQL database service being monitored is SSL-enabled, then set the SSL flag to Yes. If not, then set the SSL flag to No. |
|
Domain |
By default, none is displayed in this text box. If the ‘SQL server and Windows’ authentication has been enabled for the Azure SQL database being monitored, then the Domain parameter 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 monitored database exists. Also, in such a case, the User Name and Password that you provide should be that of a 'domain user' with DBOWNER rights to the configured Database Name. |
|
IS NTLMv2 |
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, this flag is set to No, indicating that NTLMv2 is not enabled by default for the target Microsoft Azure SQL database. Set this flag to Yes if NTLMv2 is enabled for the target database. |
|
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.*. |
|
Query Time Out (Seconds) |
Specify the time period up to which a query has to wait to obtain the required result set from the database in this 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. |
|
Percentage of High Fragmentation Limit |
Provide the limit (in percentage) of fragmentation above which an index is termed as a highly fragmented index in the this 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. |
|
Percentage of Very High Fragmentation Limit |
Provide the limit (in percentage) of fragmentation above which an index is termed as a very highly fragmented index in this 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. |
|
DD Frequency |
Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time the test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD Frequency. |
|
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:
|
| 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:
|
|
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:
|
