Locks Event Classes
The following table describes the Locks event classes in the Locks event category.
| Event class | Description |
|---|---|
| Lock:Acquired | Acquisition of a lock on a resource, such as a data page, has been achieved. For more information about resources that can be locked, see Understanding Locking in SQL Server. |
| Lock:Cancel | Acquisition of a lock on a resource has been canceled (for example, due to a deadlock). |
| Lock:Deadlock | Two concurrent transactions have deadlocked each other by trying to obtain incompatible locks on resources that the other transaction owns. For more information, see Deadlocking. |
| Lock:Deadlock Chain | This event is produced for each of the events leading up to the deadlock. |
| Lock:Escalation | A finer-grained lock has been converted to a coarser-grained lock (for example, a row lock that is converted to a page lock). |
| Lock:Released | A lock on a resource, such as a page, has been released. |
| Lock:Timeout | A request for a lock on a resource, such as a page, has timed out due to another transaction holding a blocking lock on the required resource. Time-out is determined by the @@LOCK_TIMEOUT system function and can be set with the SET LOCK_TIMEOUT statement. For more information, see Customizing the Lock Time-out. |
The Lock:Acquired and Lock:Released event classes can be used to monitor when objects are being locked, the type of locks taken, and for how long the locks were retained. Locks retained for long periods of time may cause contention and should be investigated. For example, an application can be acquiring locks on rows in a table, and then waiting for user input. Because user input can take a long time, the locks can block other users. In this instance, the application should be redesigned to make lock requests only when necessary and not require user input when locks have been acquired.
The Lock:Deadlock, Lock:Deadlock Chain, and Lock:Timeout event classes can be used to monitor when deadlocks and time-out conditions occur, and which objects are involved. This information is useful to determine whether deadlocks and time-outs are affecting the performance of your application significantly, and which objects are involved. The application code that modifies these objects can then be examined to determine whether changes to minimize deadlocks and time-outs can be made. For more information about reducing deadlocks, see Avoiding Deadlocks.