eG Monitoring
 

Measures reported by SqlAzuLockWaitTest

Lock wait event occurs when a user requests for a resource that is already locked by another user, forcing the former to wait until the latter releases the lock. Lock wait events on a database need to be minimal. If a lock is held on a resource for too long a time, all other requests will be denied access to that resource, thereby causing critical operations to fail. Moreover, if the number of lock waits grows over time, it will consequently increase the length of the pending requests queue; a long request queue may not only cause the unnecessary erosion of valuable server resources, it may also choke the database server, thereby significantly impacting the quality of the user experience with the server. It is therefore imperative that the lock wait events are monitored, and issues related to such events are immediately brought to the attention of administrators. To monitor the lock wait events for each lock type, and promptly alerts administrators to a sudden/steady increase in the number and duration of such events, eG enterprise offers SqlAzuLockWaitTest.

This test monitors the lock wait events for each lock type, and promptly alerts administrators to a sudden/steady increase in the number and duration of such events.

Outputs of the test : One set of results for the SQL Azure server being monitored

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Avg_wait_duration Indicates the duration of the lock wait events for this lock type. Seconds Ideally, this value should be very low. A high value or a consistent increase in the value may choke the database server and severely hamper its overall performance. Therefore, if the value of this measure is high, you might first need to identify what is causing the lock waits. For this purpose, you can use the detailed diagnosis of the Current lock waits measure. The detailed diagnosis leads you to the exact object the lock events are waiting on, the user who holds a lock on that object, and the query that initiated the lock. This way, inefficient queries can be identified and fine-tuned.
No_of_locks Indicates the current number of lock wait events for this lock type. Number Ideally, this value should be very low. A high value or a consistent increase in the value may choke the database server and severely hamper its overall performance. Therefore, if the value of this measure is high, you might first need to identify what is causing the lock waits. For this purpose, you can use the detailed diagnosis of this measure. The detailed diagnosis leads you to the exact object the lock events are waiting on, the user who holds a lock on that object, and the query that initiated the lock. This way, inefficient queries can be identified and fine-tuned. Given below are some tips for minimizing lock waits:

  • Keep all Transact-SQL transactions as short as possible.

  • To reduce the amount of time that tables are locked, which hurts concurrency and performance, avoid interleaving reads and database changes within the same transaction. Instead, try to do all your reads first, then perform all of the database changes (UPDATES, INSERTS, DELETES) near the end of the transaction. This helps to minimize the amount of time that exclusive locks are held.

  • Use clustered indexes on heavily used tables.

  • Make appropriate use of non-clustered indexes.

  • Try to avoid Transact-SQL statements that affect large numbers of rows at once, especially the INSERT and UPDATE statements.

  • Try to have your UPDATE and DELETE statements use an index.

  • When using nested transactions, avoid commit and rollback conflicts.