A lock is an object used by software to indicate

that a user has some dependency on a resource.

Locking is a major part of every RDBMS.
It is a database functionality which without a
multi-user environment could not work.
The main problem of locking is that in an
essence it’s a logical and not physical problem.
Types of locks
Shared (S)
Update (U)
Exclusive (X)
Intent
intent shared (IS)
intent exclusive (IX)
shared with intent exclusive (SIX)
intent update (IU)
update intent exclusive (UIX)
shared intent update (SIU)
Schema
schema modification (Sch-M)
schema stability (Sch-S)
Bulk Update (BU)
Key-Range
Shared Key-Range and Shared Resource lock (RangeS_S)
Shared Key-Range and Update Resource lock (RangeS_U)
Insert Key-Range and Null Resource lock (RangeI_N)
Exclusive Key-Range and Exclusive Resource lock (RangeX_X)
Conversion Locks (RangeI_S, RangeI_U, RangeI_X, RangeX_S, RangeX_U)
 Shared(S) Locks

This lock is applied for read operation where the

data is not updated. A good example would be
the select statement.

Shared locks are compatible with other Shared

locks or Update locks.
 Update(U) Locks
This lock is applied on those resources that can
be updated. It prevents the common form of
dead lock that occurs when multiple sessions are
locking the data so that they can update it later.

Update locks are compatible with Shared locks

only.
 Exclusive(X) Locks
Used for data-modification operations, such as
INSERT, UPDATE, or DELETE. Other
transactions cannot read or modify data locked
with an Exclusive (X) lock.
It ensures that multiple updates cannot be made
to the same resource at the same time.

Exclusive locks are not compatible with other

lock types.
 Intent Locks
Intent locks are used to protect placing a shared (S) lock or
exclusive (X) lock on a resource lower in the lock hierarchy.
Intent locks are named intent locks because they are acquired
before a lock at the lower level, and therefore signal intent to
place locks at a lower level.
Intent locks serve two purposes:
To prevent other transactions from modifying the higher-level
resource in a way that would invalidate the lock at the lower level.
To improve the efficiency of the Database Engine in detecting
lock conflicts at the higher level of granularity.
Intent Locks include:

Intent shared (IS) Protects requested or acquired shared locks on some (but not
all) resources lower in the hierarchy.
Intent exclusive (IX) Protects requested or acquired exclusive locks on some (but
not all) resources lower in the hierarchy. IX is a superset of IS, and it also
protects requesting shared locks on lower level resources.
Shared with intent exclusive (SIX) Protects requested or acquired shared locks on
all resources lower in the hierarchy and intent exclusive locks on some (but
not all) of the lower level resources. Concurrent IS locks at the top-level
resource are allowed.
Intent update (IU) Protects requested or acquired update locks on all resources
lower in the hierarchy. IU locks are used only on page resources. IU locks are
converted to IX locks if an update operation takes place.
Shared intent update (SIU) A combination of S and IU locks, as a result of
acquiring these locks separately and simultaneously holding both locks. For
example, a transaction executes a query with the PAGLOCK hint and then
executes an update operation. The query with the PAGLOCK hint acquires
the S lock, and the update operation acquires the IU lock.
Update intent exclusive (UIX) A combination of U and IX locks, as a result of
acquiring these locks separately and simultaneously holding both locks.
 Schema(Sch) Locks
Used when an operation dependent on the schema of a
table is executing.
There are two types of schema locks:
Schema stability lock (Sch-S): Used while generating
execution plans. These locks don't block access to the
object data.
Schema modification lock (Sch-M): Used while
executing a DDL statement. Blocks access to the object
data since its structure is being changed.
 Bulk Update (BU)
This lock is applied when there is a bulk copying
of data and the TABLOCK is applied or the
table lock on bulk load table option is set using
sp_tableoption.
Bulk update (BU) locks allow multiple threads to
bulk load data concurrently into the same table
while preventing other processes that are not
bulk loading data from accessing the table.
 Key-Range Locks
Key-Range locks are used by SQL Server to prevent phantom
insertions or deletions into a set of records accessed by a
transaction. Key-Range locks are used on behalf of
transactions operating at the serializable isolation level.
Shared Key-Range and Shared Resource (RangeS_S)
locks are used to indicate a serializable range scan.
Shared Key-Range and Update Resource (RangeS_U)
locks are used to indicate a serializable update scan.
Insert Key-Range and Null Resource (RangeI_N) locks
are used to test ranges before inserting a new key into an
index.
Exclusive Key-Range and Exclusive Resource
(RangeX_X) locks are used when updating a key in a range.
There are also Key-Range conversion locks.
Key-Range conversion locks include:
RangeI_S
RangeI_U
RangeI_X
RangeX_S
RangeX_U

Key-Range conversion locks are created when a Key-Range lock overlaps another
lock.

RangeI_S locks are used when RangeI_N lock overlap Shared (S) lock.
RangeI_U locks are used when RangeI_N lock overlap Update (U) lock.
RangeI_X locks are used when RangeI_N lock overlap Exclusive (X) lock.
RangeX_S locks are used when RangeI_N lock overlap RangeS_S lock.
RangeX_U locks are used when RangeI_N lock overlap RangeS_U lock.

Key-Range conversion locks are rarely used and can be observed for a short
period of time under complex circumstances.
 Locking Hints
NOLOCK
HOLDLOCK
UPDLOCK
TABLOCK
PAGLOCK
TABLOCKX
READCOMMITTED
READUNCOMMITTED
REPEATABLEREAD
SERIALIZABLE
READPAST
ROWLOCK
XLOCK
 What are Locking Hints???

Locking hints can be specified for individual table by

using the SELECT, INSERT, UPDATE, and DELETE
statements. The SQL Server query optimizer
automatically makes the correct determination. It is
recommended that locking hints be used to change the
default locking behavior only when necessary. The hints
specify the type of locking or row versioning the
instance of the SQL Server Database Engine.
 What is what?
NOLOCK Do not issue shared locks and do not honor exclusive locks.
When this option is in effect, it is possible to read an uncommitted
transaction or a set of pages that are rolled back in the middle of a read.
Dirty reads are possible. Only applies to the SELECT statement.

HOLDLOCK Hold a shared lock until completion of the transaction

instead of releasing the lock as soon as the required table, row, or data
page is no longer required. HOLDLOCK is equivalent to
SERIALIZABLE.

PAGLOCK Use page locks where a single table lock would usually be taken.

READCOMMITTED Perform a scan with the same locking semantics as a

transaction running at the READ COMMITTED isolation level.

READUNCOMMITTED Equivalent to NOLOCK.

READPAST This option causes a transaction to skip rows locked. The
READPAST lock hint applies only to transactions operating at READ
COMMITTED isolation and will read only past row-level locks. Applies only
to the SELECT statement.

REPEATABLEREAD Perform a scan with the same locking semantics as a

transaction running at the REPEATABLE READ isolation level.

SERIALIZABLE Perform a scan with the same locking semantics as a

transaction running at the SERIALIZABLE isolation level. Equivalent to
HOLDLOCK.

TABLOCK SQL Server holds this lock until the end of the statement.
However, if we specify HOLDLOCK, the lock is held until the end of the
transaction.

TABLOCKX Use an exclusive lock on a table. This lock prevents others from
reading or updating the table and is held until the end of the statement or
transaction.
UPDLOCK Use update locks instead of shared locks
while reading a table, and hold locks until the end of the
statement or transaction. UPDLOCK has the advantage
of allowing us to read data (without blocking other
readers) and update it later with the assurance that the
data has not changed since you last read it.

XLOCK Use an exclusive lock that will be held until the

end of the transaction on all data processed by the
statement. This lock can be specified with either
PAGLOCK or TABLOCK, in which case the exclusive
lock applies to the appropriate level of granularity.
Deadlocking

A deadlock occurs when two or more tasks

permanently block each other by each task having a
lock on a resource which the other tasks are trying to
lock.
Deadlocks are sometimes called a deadly embrace.
Deadlock is a condition that can occur on any system
with multiple threads, not just on a relational database
management system, and can occur for resources other
than locks on database objects.
Minimizing Deadlocks

Although deadlocks cannot be completely avoided, certain coding conventions

can minimize the chance of generating a deadlock. Minimizing deadlocks
can increase transaction throughput and reduce system overhead because
some transactions are:
Rolled back, undoing all the work performed by the transaction.
Resubmitted by applications because they were rolled back when
deadlocked.
To help minimize deadlocks:
Access objects in the same order.
Avoid user interaction in transactions.
Keep transactions short and in one batch.
Use a lower isolation level.
Use a row versioning-based isolation level.
Set READ_COMMITTED_SNAPSHOT database option ON to
enable read-committed transactions to use row versioning.
Use snapshot isolation.
Use bound connections.
View locks (sp_lock)

Sometimes you need a reference to information about

locks. Microsoft recommends using the sp_lock system
stored procedure to report locks information. This very
useful procedure returns the information about SQL
Server process ID, which lock the data, about locked
database, about locked table ID, about locked page and
about type of locking (locktype column).
 Conclusion
We should always remember that locking
problems are of LOGICAL and not physical
nature so they have to be well thought out.

Locking goes hand in hand with transaction

isolation levels so we should be familiar with
those too.
 References

http://www.mssqlcity.com/Articles/General/sql2000_locking.htm
http://www.mssqlcity.com/Articles/Adm/SQL70Locks.htm
http://msdn.microsoft.com/en-
us/library/aa213026%28v=SQL.80%29.aspx
http://articles.techrepublic.com.com/5100-10878_11-5181472.html
http://www.mssqlcity.com/Articles/Adm/LockView.htm
http://msdn.microsoft.com/en-us/library/ms191242.aspx