Locking and Blocking in SQL Server

This Article about Locking and Blocking in SQL Server is from my eBook “Tuning SQL Server (Second Edition)”

Tuning SQL Server (Second Edition)

Table of Contents | Sample Chapter | Learn More

The majority of modern relational database management systems (RDBMSs) make use of lock-based concurrency. Lock-based concurrency is the approach based on which the Database Engine of a RDBMS ensures that no actions of committed transactions are lost. This is actually what Locking is.

SQL Server Lock Modes

SQL Server locks resources using different lock modes that determine how the resources can be accessed by concurrent transactions. SQL Server uses the following lock modes:

• Shared (S)
• Update (U)
• Exclusive (X)
• Intent
• Schema
• Bulk Update (BU)
• Key-range

When Does Blocking Occur?

In RDBMSs with lock-based concurrency, such as SQL Server, there are many cases where blocking can occur. Blocking takes place when one server process id (SPID) holds a lock on one resource and a second SPID tries to place a lock of a conflicting type on the same resource. Most of the times, each blocking incident does not take much time and it is a natural behavior of RDBMs that use lock-based concurrency in order to help ensure data integrity.

There are sometimes however undesirable “blocking” incidents. Such incidents are:

• Starvation: It is the case where a transaction does not release a lock on a table/page thus forcing another transaction to wait indefinitely. SQL Server handles such issues with timeouts.
• Deadlock: It is the case where two transactions wait for each other in order to release their respective locks. SQL Server handles this by automatically selecting one of the two transactions and aborting the other along with rolling it back and sending an error message.

Learn more about SQL Server Performance Tuning in my latest eBook “Tuning SQL Server (second edition)”!