Configuration of SqlAzuIndexFragTest

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.

This page depicts the default parameters that need to be configured for the SqlAzuIndexFragTest test.

• The TEST PERIOD list box helps the user to decide how often this test needs to be executed.

• In the HOST text box, specify the IP address of the host for which the test is being configured.

• In the PORT text box, specify the port at which the specified Host listens.

• In the DATABASE NAME text box, specify the name of the Azure SQL database that is to be monitored.

• Against the USERNAME and PASSWORD parameters, specify the credentials of the user who is vested with DBOWNER rights to the configured Database Name and confirm the specified Password by retyping it in the CONFIRM PASSWORD text box.

• 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.

• 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.

• 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 IS NTLMv2 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.

• In the OBJECT NAME parameter, 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: :., 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: :.*. For example, to monitor all the tables in the admin schema, your specification would be: AlarmMon:admin.*.

• 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.

• Provide the limit (in percentage) of fragmentation above which an index is termed as a highly fragmented index in the the PERCENTAGE OF HIGH FRAGMENTATION 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.

• Provide the limit (in percentage) of fragmentation above which an index is termed as a very highly fragmented index in the PERCENTAGE OF VERY HIGH FRAGMENTATION 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.

• Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 6:1. This indicates that, by default, detailed measures will be generated every sixth time this 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.

• 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.

• Once the above values are provided, click on the UPDATE button to register the changes made.

When changing the configuration for specific servers, a “*” beside the text box corresponding to the parameter signifies that these values have to be manually configured by the user. The parameter values that require to be configured will typically be prefixed with a “$” or contain a series of “*”. A value of “none” in the parameter value indicates that the corresponding parameter value can be changed if required.