Locking is handled
automatically in SQL Server. The Lock Manager chooses the type of lock,
based on the type of transaction (such as SELECT, INSERT, UPDATE, or DELETE). Lock Manager uses the following types of locks:
In addition to choosing the type of lock, the Lock
Manager in SQL Server 2008 automatically adjusts the granularity of the
locks (for example, row, page, table), based on the nature of the
statement that is executed and the number of rows that are affected.
Shared Locks
By
default, SQL Server uses shared locks for all read operations. A shared
lock is, by definition, not exclusive. Theoretically, an unlimited
number of shared locks can be held on a resource at any given time. In
addition, shared locks are unique in that, by default, a process locks a
resource only for the duration of the read on the resource (row, page,
or table). For example, the query SELECT * from authors locks the first row in the authors
table when the query starts. After the first row is read, the lock on
that row is released, and a lock on the second row is acquired. After
the second row is read, its lock is released, and a lock on the third
row is acquired, and so on. In this fashion, a SELECT query
allows other data rows that are not being read to be modified during the
read operation. This increases concurrent access to the data.
Shared locks are compatible with other shared locks
as well as with update locks. A shared lock does not prevent the
acquisition of additional shared locks or an update lock by other
processes on a given row or page. Multiple shared locks can be held at
any given time, for a number of transactions or processes. These
transactions do not affect the consistency of the data. However, shared
locks do prevent the acquisition of exclusive locks. Any transaction
attempting to modify data on a page or a row on which a shared lock is
placed is blocked until all the shared locks are released.
Note
It is important to note that within a transaction
running at the default isolation level of Read Committed, shared locks
are not held for the duration of the transaction or even the duration of
the statement that acquires the shared locks. Shared lock resources
(row, page, table, and so on) are normally released as soon as the read
operation on the resource is completed. SQL Server provides the HOLDLOCK clause for the SELECT statement, which you can use if you want to continue holding the shared lock for the duration of the transaction.
Update Locks
Update locks are used to lock rows or pages that a
user process intends to modify. When a transaction tries to update a
row, it must first read the row to ensure that it is modifying the
appropriate record. If the transaction were to put a shared lock on the
resource initially, it would eventually need to get an exclusive lock on
the resource to modify the record and prevent any other transaction
from modifying the same record. The problem is that this could lead to
deadlocks in an environment in which multiple transactions are trying to
modify data on the same resource at the same time. Figure 1
demonstrates how deadlocks can occur if lock conversion takes place
from shared locks to exclusive locks. When both processes attempt to
escalate the shared lock they both hold on a resource to an exclusive
lock, it results in a deadlock situation.
Update
locks in SQL Server are provided to prevent this kind of deadlock
scenario. Update locks are partially exclusive in that only one update
lock can be acquired at a time on any resource. However, an update lock
is compatible with shared locks, in that both can be acquired on the
same resource simultaneously. In effect, an update lock signifies that a
process wants to change a record, and it keeps out other processes that
also want to change that record. However, an update lock allows other
processes to acquire shared locks to read the data until the UPDATE or DELETE
statement is finished locating the records to be affected. The process
then attempts to escalate each update lock to an exclusive lock. At this
time, the process waits until all currently held shared locks on the
same records are released. After the shared locks are released, the
update lock is escalated to an exclusive lock. The data change is then
carried out, and the exclusive lock is held for the remainder of the
transaction.
Note
Update locks are not used just for update operations.
SQL Server uses update locks any time a search for data is required
prior to performing the actual modification, such as with qualified
updates and deletes (that is, when a WHERE clause is
specified). Update locks are also used for insertions into a table with a
clustered index because SQL Server must first search the data and
clustered index to identify the correct position at which to insert the
new row to maintain the sort order. After SQL Server has found the
correct location and begins inserting the record, it escalates the
update lock to an exclusive lock.
Exclusive Locks
As mentioned earlier, an exclusive lock is granted to
a transaction when it is ready to perform data modifications. An
exclusive lock on a resource makes sure no other transaction can
interfere with the data locked by the transaction that is holding the
exclusive lock. SQL Server releases the exclusive lock at the end of the
transaction.
Exclusive
locks are incompatible with other lock types. If an exclusive lock is
held on a resource, any other read or data modification request for the
same resource by other processes is forced to wait until the exclusive
lock is released. Likewise, if a resource currently has read locks held
on it by other processes, the exclusive lock request is forced to wait
in a queue for the resource to become available.
Intent Locks
Intent locks do not really constitute a locking mode;
rather, they act as a mechanism to indicate at a higher level of
granularity the types of locks held at a lower level. The types of
intent locks mirror the lock types previously discussed: shared intent
locks, exclusive intent locks, and update intent locks. SQL Server Lock
Manager uses intent locks as a mechanism to indicate that a shared,
update, or exclusive lock is held at a lower level. For example, a
shared intent lock on a table by a process signifies that the process
currently holds a shared lock on a row or page within the table. The
presence of the intent lock prevents other transactions from attempting
to acquire a table-level lock that would be incompatible with the
existing row or page locks.
Intent locks improve locking performance by allowing
SQL Server to examine locks at the table level to determine the types of
locks held on the table at the row or page level rather than searching
through the multiple locks at the page or row level within the table.
Intent locks also prevent two transactions that are both holding locks
at a lower level on a resource from attempting to escalate those locks
to a higher level while the other transaction still holds the intent
lock. This prevents deadlocks during lock escalation.
You typically see three types of intent locks when monitoring locking activity: intent shared (IS) locks, intent exclusive (IX) locks, and shared with intent exclusive (SIX) locks. An IS
lock indicates that the process currently holds, or has the intention
of holding, shared locks on lower-level resources (row or page). An IX lock indicates that the process currently holds, or has the intention of holding, exclusive locks on lower-level resources. An SIX (pronounced as the letters S-I-X,
not like the number six) lock occurs under special circumstances when a
transaction is holding a shared lock on a resource, and later in the
transaction, an IX lock is needed. At that point, the IS lock is converted to an SIX lock.
In the following example, the SELECT
statement running at the serializable level acquires a shared table
lock. It then needs an exclusive lock to update the row in the sales_big table:
SET TRANSACTION ISOLATION LEVEL serializable
go
BEGIN TRAN
select sum(qty) FROM sales_big
UPDATE sales_big
SET qty = 0
WHERE sales_id = 1001
COMMIT TRAN
Because the transaction initially acquired a shared (S) table lock and then needed an exclusive row lock, which requires an intent exclusive (IX) lock on the table within the same transaction, the S lock is converted to an SIX lock.
Note
If only a few rows were in sales_big, SQL
Server might acquire only individual row or key locks rather than a
table-level lock. SQL Server would then have an intent shared (IS) lock on the table rather than a full shared (S) lock. In that instance, the UPDATE statement would then acquire a single exclusive lock to apply the update to a single row, and the X lock at the key level would result in the IS locks at the page and table levels being converted to an IX lock at the page and table level for the remainder of the transaction.
Schema Locks
SQL Server uses schema locks to maintain structural
integrity of SQL Server tables. Unlike other types of locks that provide
isolation for the data, schema locks provide isolation for the schema
of database objects, such as tables, views, and indexes within a
transaction. The Lock Manager uses two types of schema locks:
Schema stability locks—
When a transaction is referencing either an index or a data page, SQL
Server places a schema stability lock on the object. This ensures that
no other process can modify the schema of an object—such as dropping an
index or dropping or altering a stored procedure or table—while other
processes are still referencing the object.
Schema modification locks—
When a process needs to modify the structure of an object (for example,
alter the table, recompile a stored procedure), the Lock Manager places
a schema modification lock on the object. For the duration of this
lock, no other transaction can reference the object until the changes
are complete and committed.
Bulk Update Locks
A bulk update lock is a special type of lock used only when bulk copying data into a table using the bcp utility or the BULK INSERT command. This special lock is used for these operations only when either the TABLOCK hint is specified to bcp or the BULK INSERT command or when the table lock on bulk load table option has been set for the table. Bulk update locks allow multiple bulk copy processes to bulk copy data into the same table
in parallel, while preventing other processes that are not bulk copying
data from accessing the table. If there are any indexes on the table,
or any other processes already holding locks on the table, a bulk update
lock cannot be granted.
