ISQL Users Group September 2009
SQL Server
Locking and Concurrency
[email protected]
www.sqlserverutilities.com
blogs.microsoft.co.il/blogs/yaniv_etrogi
1
Concurrency Models
Pessimistic Concurrency
Optimistic Concurrency
2
Pessimistic Concurrency
Locks are acquired on data being read
Preventing other processes from modifying
that data
Other processes can still read the data
Locks are acquired on data being
modified
Preventing other processes from modifying
that data
Preventing other processes from reading
that data
3
Optimistic Concurrency
Readers see the state of the data before the
modification occurred using Row versioning
Writers are unaffected by Readers because all
read operations are accessing a saved version
of the data
Readers do not block Writers
Writers do not block Readers
Writers can block Writers which generates a
conflict and then it is up to the application to
handle the conflict.
4
Isolation Levels
Read Uncommitted (Pessimistic Concurrency)
Read Committed (Pessimistic Concurrency)
Repeatable Read (Pessimistic Concurrency)
Serializable (Pessimistic Concurrency)
Snapshot (Optimistic Concurrency)
5
Isolation Levels 1
Read Uncommitted
Readers read uncommitted data
Read operations do not acquire share
locks
Read operations disregard shared locks
acquired by other connections
Non-repeatable reads and phantoms are
possible
6
Isolation Levels 2
Read Committed
Readers can only read data that has been committed
Read operations acquire share locks
Share locks acquired by other processes are honored
Non-repeatable reads and phantoms are possible
If the database setting READ_COMMITTED_SNAPSHOT is
ON then the READ Committed isolation level works in an
Optimistic Concurrency Model
This is also known as READ Committed Snapshot
7
Isolation Levels 3
Repeatable Read
Does not allow a non-repeatable read
Phantoms are possible
If a SELECT statement is reissued within
the same transaction it is guaranteed to
retrieve the same data as was retrieved
in the previous SELECT but new rows
can exist in the set of data retreived
8
Isolation Levels 4
Serializable
Phantoms are not possible
If a SELECT statement is reissued within
the same transaction it is guaranteed to
retrieve the same data as was retrieved
in the previous SELECT and no new rows
can exist in the set of data
9
Isolation Levels 5
Snapshot
Like in the Read Committed
snapshot processes can read older
versions of committed data if the
current version is locked
10
Lock Modes
http://msdn.microsoft.com/en-us/library/ms175519.aspx
11
Shared Locks
Acquired when data is read
Acquired on a table, page, index key or a row
Many processes can acquire shared locks on
the same data
No process can acquire an exclusive lock on
data that has a shared lock on it
unless the process requesting the exclusive lock is the
same process holding the shared lock
12
Exclusive Locks
Acquired on data when the data is modified by
any DML statement (INSERT, UPDATE,
DELETE, SELECT INTO, MERGE)
Only one process at a given time can hold an
exclusive lock on the same data resource
No locks of any kind can be acquired by a
process if another process has the requested
data resource exclusively locked
Exclusive locks are held until the end of the
transaction
13
Update Locks
Acquired when a data modification statement executes
but first there is a need to search for the data behind
the scenes before the actual DML can take place
For example - An INSERT into a table with a clustered
index requires first to search the data in order to find
the correct position at which to locate the new row.
During that search time an UPDATE locks is acquired for
the sake of protecting the data
Using a hints a process can explicitly request an
UPDATE lock
14
Intent Locks
Intent locks are a “mix” of the Locks
modes previously discussed
Intent locks serve as meta data for
cases such as when a process needs to lock
a table it first needs to determine if a row
or a page of that table is already locked
15
Schema Locks
schema stability
schema modification
bulk update
schema stability locks and schema modification
locks are acquired when a DDL statement such as
ALTER TABLE is issued in order to protect the table
structure while there are statements already
issued that refer to the object in it’s current
version, that is before the schema modification
bulk update lock is acquired when using the bcp
(in) utility or when a BULK INSERT command is
issued
16
Conversion Locks
Conversion locks are the result of a
conversion from one lock mode to
another
SIX
SIU
UIX
See example
17
Key Locks
In the Read Committed, Repeatable
Read and Snapshot isolation levels Key
Locks are used to lock the index keys
When a clustered index exists the data rows are the leaf
level of the index and key locks are acquired
When the table is a heap key locks can be acquired on
the non-clustered indexes and row locks (RID) for the
actual data
In the Serializable isolation level key-
range locks are used to lock the entire
range(s) in order to prevent phantoms
See example 18
Key Locks Types
There are nine types of
key-range locks and each has
a two-part name
The first part indicates the type of lock on
the range of data between index keys
The second part indicates the type of lock
on the key itself
19
Key Locks Details
RangeS-S
Shared lock on the range between keys; shared lock on the key at
the end of the range
RangeS-U
Shared lock on the range between keys; update lock on the key at
the end of the range
RangeIn-Null
Exclusive lock to prevent inserts on the range between keys; no
lock on the keys themselves
RangeX-X
Exclusive lock on the range between keys; exclusive lock on the
key at the end of the range
20
Key Locks Details 2
RangeIn-S
Conversion lock created by S and RangeIn_Null lock
RangeIn-U
Conversion lock created by U and RangeIn_Null lock
RangeIn-X
Conversion of X and RangeIn_Null lock
RangeX-S
Conversion of RangeIn_Null and RangeS_S lock
RangeX-U
Conversion of RangeIn_Null and RangeS_U lock
21
Lock Duration
The duration a lock is held depends on the mode of the
lock and the transaction isolation level in effect
In Read Committed and Snapshot shared locks are
released as soon as the data is read and processed
In Repeatable Read and Serializable shared locks have
the same duration as exclusive locks
Shared Locks are not released until the transaction is
over
In all isolation levels exclusive locks are held until the
end of the transaction
An update lock is also held until the end of the
transaction
22
Lock Compatibility
Two locks are compatible if one lock can
be granted while another lock on the
same resource is already held by a
different process
Two connections can hold a shared lock on the same
row or page
If a lock requested for a resource is not
compatible with a lock currently being
held the requesting connection must
wait for the lock
If a shared page lock is held on a page and another
connection requests an exclusive page lock it will wait
23
Lock Compatibility matrix
http://msdn.microsoft.com/en-us/library/ms186396.aspx
24
Lock Starvation
By examining the compatibility of locks not only with
processes granted but also processes waiting SQL
Server prevents lock starvation which can result when
requests for shared locks keep overlapping so that the
request for the exclusive lock can never be granted
P1 holds a shared page lock
P2 requests an exclusive page lock and waits
P3 requests a shared page lock that is
compatible with the shared page lock held by P1
P3 waits for its shared page lock because
P2 is ahead of it in the lock queue with a
request (exclusive page) that is not compatible even though
P3 request’s is compatible with P1
25
Lock Escalation
SQL Server automatically escalates row, key, or page
locks to table locks
SQL Server never escalates to page locks and it is not
possible to lock just a single partition of a table or
index. The result of a lock escalation is always a full
table lock
SQL Server 2008 allows escalation at the partition level
A statement that acquires many individual row locks
can be escalated to a table lock
It is lighter to acquire and maintain a single table lock
than to hold many individual row locks
Lock escalation reduces locking overhead and keeps the
system from running out of locks
26
Lock Escalation 2
The number of locks held by a single statement on one
object (index or heap) exceeds a threshold (~5000)
Memory consumed by lock resources exceeds 40
percent of the non-AWE (32-bit) or regular (64-bit)
enabled memory
The server wide settings “Locks” effects the total
memory available
0 = dynamically allocated
A Lock escalation attempt can fall due to lock
compatibility and in this case SQL Server will continue
and try to escalate the lock every time the transaction
acquires another 1,250 locks on the same object
27
Lock Escalation 3
The CREATE/ ALTER TABLE command can
also have an impact on Locks and Lock
escalation
ALLOW_ROW_LOCKS = { ON | OFF }
Row locks are allowed when accessing the index
ALLOW_PAGE_LOCKS = { ON | OFF }
Page locks are allowed when accessing the index
SQL Server 2008 only
SET ( LOCK_ESCALATION = { AUTO | TABLE | DISABLE } )
This is a definition on a per table specific basis
28
Lock Escalation 4
The CREATE/ ALTER INDEX command can also
impact the way data is accessed and locked
When ALLOW_ROW_LOCKS = ON and
ALLOW_PAGE_LOCK = ON: row level, page
level and table level locks are allowed when
you access the index
When ALLOW_ROW_LOCKS = OFF and
ALLOW_PAGE_LOCK = OFF: only a table
level lock is allowed when you access the
index
The index "IX_Parts" (partition 1) on table
"Parts" cannot be reorganized because page
level locking is disabled 29
Disable Lock Escalation
DBCC TRACEON (1211);
Completely disables lock escalation.
instructs SQL Server to ignore the memory
acquired by the lock manager up to the maximum
statically allocated lock memory
DBCC TRACEON (1224);
Disables lock escalation based on the number of
locks acquired but allows escalation based on
memory consumption
It enables lock escalation when the lock manager acquires 40 percent of the
statically allocated memory.
SQL Server generates an out-of-memory error when memory
allocated to the lock manager exceeds the total allocated
memory
DBCC TRACESTATUS (-1)
30
Control Locking using Hints
Effect the table referenced in the FROM clause
A hint applied to a Read operation mostly requires an explicit
transaction to take effect
Any DML anyhow executes as an implicit transaction
SELECT * FROM T1 WITH (lock hint) …
DELETE FROM T1 WITH (lock hint) …
UPDATE T1 WITH (lock hint) …
INSERT T1 WITH (lock hint) …
31
Lock Hints
HOLDLOCK – serializes access same as
SERIALIZABLE
UPDLOCK - acquires update page locks instead
of shared page locks while data being read
TABLOCK - acquires a shared lock on the table
Useful when you know you'll escalate to a table lock
Useful when you need to get a snapshot of a table
Combined with HOLDLOCK exclusively locks the table
PAGLOCK - acquires shared page locks
Combined with XLOCK exclusively lock a page
32
Lock Hints 2
TABLOCKX - exclusively locks the table
Equal to (TABLOCK , XLOCK )
ROWLOCK - Acquires a shared row lock
NOLOCK - Allows uncommitted reads (dirty
reads)
Shared locks are not acquired when data is read
Exclusive locks of other processes are disregarded
Equivalent to READUNCOMMITTED
READPAST - Locked rows are skipped (read
past)
Applies only to transactions at READ COMMITTED isolation level
Reads past row-level locks only
33
Lock Hints 3
XLOCK - Acquires an exclusive lock on all data processed by the
statement
If combined with ROWLOCK, PAGLOCK, or TABLOCK, the exclusive locks apply to the
appropriate level of granularity
READUNCOMMITTED | REPEATABLEREAD | SERIALIZABLE -
imply the same locking mechanisms as when the transaction
isolation level is set to the level of the same name
READCOMMITTED – Read operations comply with the
rules for the READ COMMITTED isolation level by using
either locking or row versioning
If the database option READ_COMITTED_SNAPSHOT is OFF SQL Server uses shared
locks and releases them as soon as the read operation is completed
If the database option READ_COMMITTED_SNAPSHOT is ON, SQL Server does not
acquire locks and uses row versioning
READCOMMITTEDLOCK - Read operations use the locking
version of READCOMMITTED isolation (the default)
Regardless the database setting for the READ_COMMITTED_SNAPSHOT
Shared locks acquired when data is read and released as soon as the read operation is
completed
34
Setting a Lock Timeout
By default there is no time out when waiting
for a lock
Typically there is a time out defined in the
client library
When a connection exceeds the time out defined at the
client library and gets terminated you do not know the
reason for the disconnection
LOCK_TIMEOUT defined at the database level clearly
informs the cause to the disconnection in the form of
error number 1222
LOCK_TIMEOUT = 0 means that SQL Server
does not wait at all for locks
Watch example
35
Resolving Blocking
Writer/Writer
Make write transactions as short as possible
which reduces the time exclusive locks are
held
Verify you do not work in an isolation level
stricter than required
Verify required indexes exist
Perform mass operation in chunks to avoid
lock escalation and possibly at off peak hours
36
Resolving Blocking
Reader/Writer
Use the READ UNCOMMITTED isolation level
Only where applicable and after a through thinking
Use Hints where applicable (always with care)
Verify you do not work in an isolation level stricter than
required
Direct heavy Read operations to read data from another
database or another server
Use the row-versioning–based Snapshot Isolation levels
37
?
38
SQL Server BOL (Books Online)
sys.dm_os_wait_stats
http://msdn.microsoft.com/en-us/library/ms179984.aspx
sys.dm_tran_locks
http://msdn.microsoft.com/en-us/library/ms190345.aspx
Inside Microsoft SQL Server 2005
http://www.insidesqlserver.com/thebooks.html
39
