Lock granularity is
essentially the amount of data locked as part of a query or update to
provide complete isolation and serialization for the transaction. The
Lock Manager needs to balance the concurrent access to resources versus
the overhead of maintaining a large number of lower-level locks. For
example, the smaller the lock size, the greater the number of concurrent
users who can access the same table at the same time but the greater
the overhead in maintaining those locks. The greater the lock size, the
less overhead required to manage the locks, but concurrency is also
less. Figure 1 demonstrates the trade-offs between lock size and concurrency.
Currently, SQL Server balances performance and
concurrency by locking at the row level or higher. Based on a number of
factors, such as key distribution, number of rows, row density, search
arguments (SARGs), and so on, the Query Optimizer makes lock granularity
decisions internally, and the programmer does not have to worry about
such issues. SQL Server provides a number of T-SQL extensions that give
you better control over query behavior from a locking standpoint.
SQL Server provides the following locking levels:
DATABASE— Whenever a SQL Server process is using a database other than master,
the Lock Manager grants a database lock to the process. These are
always shared locks, and they are used to keep track of when a database
is in use to prevent another process from dropping the database, setting
the database offline, or restoring the database. Note that because master and tempdb cannot be dropped or set offline, database locks are not required on those databases.
FILE— A file lock is a lock acquired on a database file.
EXTENT—
Extent locks are used for locking extents, usually only during space
allocation and deallocation. An extent consists of eight contiguous data
or index pages. Extent locks can be shared extent or exclusive extent
locks.
ALLOCATION_UNIT— This type of lock is acquired on a database allocation unit.
TABLE— With
this type of lock, the entire table, inclusive of data and indexes, is
locked. Examples of when table-level locks may be acquired include
selecting all rows from a large table at the serializable level and
performing unqualified updates or deletes on a table.
Heap or B-Tree (HOBT)— This type of lock is acquired on a heap of data pages or on the B-Tree structure of an index.
PAGE—
With a page lock, the entire page, consisting of 8KB of data or index
information, is locked. Page-level locks might be acquired when all rows
on a page need to be read or when page-level maintenance needs to be
performed, such as updating page pointers after a page split.
Row ID (RID)—
With an RID lock, a single row within a page is locked. RID locks are
acquired whenever efficient and possible to do so in an effort to
provide maximum concurrent access to the resource.
KEY—
SQL Server uses two types of key locks. The one that is used depends on
the locking isolation level of the current session. For transactions
that run in Read Committed or Repeatable Read isolation modes, SQL
Server locks the actual index keys associated with the rows being
accessed. (If a clustered index is on the table, the data rows are the
leaf level of the index. You see key locks instead of row locks on those
rows.) When in Serializable Read isolation mode, SQL Server prevents
phantom rows by locking a range of key values so that no new rows can be
inserted into the range. These are referred to as key-range locks.
Key-range locks associated with a particular key value lock that key
and the previous one in the index to indicate that all values between
them are locked. Key-range locks are covered in more detail in the next
section.
METADATA— This type of lock is acquired on system catalog information
APPLICATION—
An application lock allows users to essentially define their own locks
by specifying a name for the resource, a lock mode, an owner, and a
timeout interval.
1. Serialization and Key-Range Locking
SQL Server provides serialization (Isolation Level 3) through the SET TRANSACTION ISOLATION SERIALIZABLE
command. One of the isolations provided by this isolation level is the
prevention against phantom reads. Preventing phantom reads means that
the recordset that a query obtains within a transaction must return the
same result set when it is run multiple times within the same
transaction. That is, while a transaction is active, another transaction
should not be allowed to insert new rows that would appear in the
recordset of a query that were not in the original recordset retrieved
by the transaction. SQL Server provides this capability though key-range
locking.
Key-range
locking in SQL Server provides isolation for a transaction from data
modifications made by other transactions. This means that a transaction
should return the same recordset each time. The following sections show
how key-range locking
works with various lock modes. Key-range locking covers the scenarios of
a range search that returns a result set as well as searches against
nonexistent rows.
Key-Range Locking for a Range Search
In a scenario that involves key-range locking for a
range search, SQL Server places locks on the index pages for the range
of data covered in the WHERE clause of the query. (For a
clustered index, the rows would be the actual data rows in the table.)
Because the range is locked, no other transaction can insert new rows
that fall within the range. In Figure 2, for example, transaction A has issued the following SELECT statement:
Set transaction isolation level serializable
begin tran
select * from bigpubs2008..stores
where stor_id between '6000' and '7500'
and state = 'CA'
Transaction B is performing the following INSERT statement, attempting to insert a row that falls within the range being retrieved by transaction A (stor_id >= '6000' and stor_id <= '7500'):
begin tran
insert bigpubs2008..stores
values ('7200', 'Test Stores', '2 Williams Ct','Lexington', 'MA', '02154')
Listing 1 shows the locks acquired when using the sys.dm_tran_locks catalog view. (In this sample output, SPID 53 is executing the SELECT statement, and SPID 57 is attempting the INSERT.)
Listing 1. Viewing Key-Range Locks Using the sys.dm_tran_locks View
select str(request_session_id, 4,0) as spid,
convert (varchar(12), db_name(resource_database_id)) As db_name,
case when resource_database_id = db_id() and resource_type = 'OBJECT'
then convert(char(20), object_name(resource_Associated_Entity_id))
else convert(char(20), resource_Associated_Entity_id)
end as object,
convert(varchar(12), resource_type) as resource_type,
convert(varchar(10), request_mode) as mode,
convert(varchar(8), request_status) as status
from sys.dm_tran_locks
order by request_session_id, 3 desc
go
spid db_name object resource_type mode status
---- ------------ --------------- ------------- ---------- --------
52 msdb 0 DATABASE S GRANT
53 bigpubs2008 391941215944704 PAGE IS GRANT
53 bigpubs2008 391941215944704 KEY RangeS-S GRANT
53 bigpubs2008 391941215944704 KEY RangeS-S GRANT
53 bigpubs2008 391941215944704 KEY RangeS-S GRANT
53 bigpubs2008 391941215944704 KEY RangeS-S GRANT
53 bigpubs2008 391941215944704 KEY RangeS-S GRANT
53 bigpubs2008 1685581043 OBJECT IS GRANT
53 bigpubs2008 0 DATABASE S GRANT
57 bigpubs2008 673416192655360 PAGE IX GRANT
57 bigpubs2008 673416192655360 KEY X GRANT
57 bigpubs2008 391941215944704 PAGE IX GRANT
57 bigpubs2008 391941215944704 PAGE IX GRANT
57 bigpubs2008 391941215944704 KEY RangeI-N WAIT
57 bigpubs2008 391941215944704 KEY RangeI-N GRANT
57 bigpubs2008 391941215944704 KEY X GRANT
57 bigpubs2008 391941215944704 PAGE IX GRANT
57 bigpubs2008 1685581043 OBJECT IX GRANT
57 bigpubs2008 0 DATABASE S GRANT
|
To provide key-range isolation, SQL Server places RangeS-S
locks (that is, a shared lock on the key range and a shared lock on the
key at the end of the range) on the index keys for the rows with the
matching values. It also places intent share (IS) locks on the page(s) and the table that contain the rows. The insert process acquires intent exclusive (IX) locks on the destination page(s) and the table. In this case, the insert process is waiting for a RangeIn-Null lock on the key range until the RangeS-S locks in the key range are released. The RangeIn-Null
lock is an exclusive lock on the range between keys, with no lock on
the key. This lock is acquired because the insert process is attempting
to insert a new store ID that has no associated key value.
Key-Range Locking When Searching Nonexistent Rows
In a
scenario that involves key-range locking when searching nonexistent
rows, if a transaction is trying to delete or retrieve a row that does
not exist in the database, it still should not find any rows at a later
stage in the same transaction with the same query. For example, in Figure 3, Transaction A is trying to fetch a nonexistent row with the key value 7200 using the following query:
SET TRANSACTION ISOLATION LEVEL serializable
go
BEGIN TRAN
select * FROM bigpubs2008..stores
where stor_id = '7200'
In another concurrent transaction, Transaction B is
executing the following statement to insert a record with the same key
value (stor_id = 7200):
begin tran
insert bigpubs2008..stores
values ('7200', 'Test Stores', '2 Williams Ct','Lexington', 'MA', '02154')
In this mode, SQL Server prevents Transaction B (SPID 57) from inserting a new row by using a RangeS-S lock for Transaction A (SPID 53). This lock is placed on the index key rows for the rows in the range between MAX(stor_id) < 7200 (key value 7100 in Figure 37.8) and MIN(stor_id) > 7200 (key value 7300 in Figure 37.8). Transaction B holds a RangeIn-Null lock and waits for the RangeS-S lock to be released.
Listing 2 provides an example of the query against the sys.dm_tran_locks catalog view for these two transactions.
Listing 2. Viewing Key-Range Locks on Nonexistent Row
select str(request_session_id, 4,0) as spid,
convert (varchar(12), db_name(resource_database_id)) As db_name,
case when resource_database_id = db_id() and resource_type = 'OBJECT'
then convert(char(20), object_name(resource_Associated_Entity_id))
else convert(char(20), resource_Associated_Entity_id)
end as object,
convert(varchar(12), resource_type) as resource_type,
convert(varchar(10), request_mode) as mode,
convert(varchar(8), request_status) as status
from sys.dm_tran_locks
order by request_session_id, 3 desc
go
spid db_name object resource_type mode status
---- ------------ --------------- ------------- ---------- --------
53 bigpubs2008 391941215944704 PAGE IS GRANT
53 bigpubs2008 391941215944704 KEY RangeS-S GRANT
53 bigpubs2008 1685581043 OBJECT IS GRANT
53 bigpubs2008 0 DATABASE S GRANT
57 bigpubs2008 391941215944704 PAGE IX GRANT
57 bigpubs2008 391941215944704 KEY RangeI-N WAIT
57 bigpubs2008 1685581043 OBJECT IX GRANT
57 bigpubs2008 0 DATABASE S GRANT
|
