Lock Granularity and Hierarchies
The Microsoft SQL Server Database Engine has multigranular locking that allows different types of resources to be locked by a transaction. To minimize the cost of locking, the Database Engine locks resources automatically at a level appropriate to the task. Locking at a smaller granularity, such as rows, increases concurrency but has a higher overhead because more locks must be held if many rows are locked. Locking at a larger granularity, such as tables, are expensive in terms of concurrency because locking an entire table restricts access to any part of the table by other transactions. However, it has a lower overhead because fewer locks are being maintained.
The Database Engine often has to acquire locks at multiple levels of granularity to fully protect a resource. This group of locks at multiple levels of granularity is called a lock hierarchy. For example, to fully protect a read of an index, an instance of the Database Engine may have to acquire share locks on rows and intent share locks on the pages and table.
The following table shows the resources that the Database Engine can lock.
Resource |
Description |
|---|---|
RID |
A row identifier used to lock a single row within a heap. |
KEY |
A row lock within an index used to protect key ranges in serializable transactions. |
PAGE |
An 8-kilobyte (KB) page in a database, such as data or index pages. |
EXTENT |
A contiguous group of eight pages, such as data or index pages. |
HoBT |
A heap or B-tree. A lock protecting a B-tree (index) or the heap data pages in a table that does not have a clustered index. |
TABLE |
The entire table, including all data and indexes. |
FILE |
A database file. |
APPLICATION |
An application-specified resource. |
METADATA |
Metadata locks. |
ALLOCATION_UNIT |
An allocation unit. |
DATABASE |
The entire database. |
Note
HoBT and TABLE locks can be affected by the LOCK_ESCALATION option of ALTER TABLE.