The document discusses database locks and transaction isolation levels. It begins by defining shared, exclusive, and update locks. It then explains different isolation levels including read uncommitted, read committed, repeatable read, and serializable. Read uncommitted allows dirty reads while read committed does not. Repeatable read prevents non-repeatable reads and serializable prevents phantom records. The document also covers snapshot isolation and how to avoid deadlocks through proper database design and transaction ordering.

1. Deadlock detected! All is lost or it's
too early to sound the alarm?
Denis Reznik

2. Sponsors

3. About me





3 |
Denis Reznik
Kiev, Ukraine
Database Architect at The Frayman Group
Microsoft MVP
Community enthusiast

4. Agenda
 Locks
 Lock Types
 Transaction Isolation Levels
 Deadlocks
 Classic Deadlocks
 Not obvious deadlocks
 Deadlock detecting and analyzing

5. Lock Types- Shared
X
S
S

6. Lock Types - Exclusive
S
X
X

7. Lock Types - Update
S
U
X
U
S

8. Lock Types – Intent locks
IS
S
IS

9. READ UNCOMMITTED
 The less restricted Isolation Level
 Allow all collisions, which READ
COMMITTED allow
 Allow Dirty Reads
 Doesn’t set Shared locks on read operations

10. Demo
READ UNCOMMITTED

11. DIRTY READS
SELECT * FROM Users
WHERE City = 'Kiev'
ID
Sofia
Kiev
2
Sofia
3
Sofia
Sofia
SELECT * FROM Users
WHERE City = 'Kiev'
5
ROLLBACK
1
4
BEGIN TRAN
X
UPDATE Users
SET City = 'Sofia'
WHERE City = 'Kiev'
City
Moscow
0 Records
6
New York
7
New York
SELECT * FROM Users
WHERE City = 'Kiev'

12. READ COMMITTED
 Default Isolation Level
 Doesn’t allow Dirty Reads
 Shared locks released after the read

13. NO DIRTY READS
ID
BEGIN TRAN
UPDATE Users
SET City = 'Sofia'
WHERE City = 'Kiev'
X
City
1
Sofia
Kiev
2
Sofia
3
Sofia
4
Sofia
5
Moscow
6
New York
7
New York
SELECT * FROM Users
WHERE City = 'Kiev'
S
SELECT * FROM Users
WHERE City = 'Kiev'
Wait for
Shared lock
on the row

14. Demo
READ COMMITTED

15. NON-REPEATABLE READS
BEGIN TRAN
ID
UPDATE Users
SET City = 'Kiev'
WHERE Id = 2
1
X
City
Kiev
2
Sofia
Kiev
S
3
Sofia
4
Sofia
S ...
S
5
Moscow
6
New York
7
New York
SELECT * FROM Users
WHERE City = 'Sofia'
SELECT * FROM Users
WHERE City = 'Sofia'

16. REPEATABLE READ




More restricted than READ COMMITTED
Doesn’t allow Dirty Reads
Doesn’t allow Non-Repeatable reads
Shared locks are hold to the end of the
transaction

17. NO NON-REPEATABLE READS
BEGIN TRAN
ID
UPDATE Users
SET City = ‘Kiev'
WHERE Id = 2
1
X
City
Kiev
2
Sofia
Kiev
S
3
Sofia
4
Sofia
S ...
S
5
Moscow
6
New York
7
New York
SELECT * FROM Users
WHERE City = 'Sofia'
SELECT * FROM Users
WHERE City = 'Sofia'
COMMIT

18. Demo
REPEATABLE READ

19. PHANTOM RECORDS
BEGIN TRAN
ID
UPDATE Users
SET City = 'Sofia'
WHERE Id = 'Kiev'
X
City
1
Sofia
Kiev
S
2
Sofia
S
3
Sofia
4
Sofia
S ...
S
5
Moscow
6
New York
7
New York
SELECT * FROM Users
WHERE City = 'Sofia'
SELECT * FROM Users
WHERE City = 'Sofia'

20. SERIALIZABLE





The most restricted Isolation Level
Doesn’t allow Dirty Reads
Doesn’t allow Non-Repeatable reads
Doesn’t allow Phantom Records
Lock range of keys

21. NO PHANTOM RECORDS
BEGIN TRAN
UPDATE Users
SET City = 'Sofia'
WHERE Id = 'Kiev'
X
City
1
Sofia
Kiev
2
Sofia
3
Sofia
4
Sofia
5
Moscow
6
New York
7
New York
RANGE S-S
ID
SELECT * FROM Users
WHERE City = 'Sofia'
...
SELECT * FROM Users
WHERE City = 'Sofia'
COMMIT

22. Demo
SERIALIZABLE

23. READ COMMITTED SNAPSHOT




Optimistic concurrency for reads
Use row-version store in tempdb
No shared locks on reads
The same collisions as in READ
COMMITTED

24. READ COMMITTED SNAPSHOT
ID
BEGIN TRAN
X
UPDATE Users
SET City = 'Sofia'
WHERE City = 'Kiev'
Version Store
ID
City
1
Kiev
tempdb
City
1
Sofia
Kiev
2
Sofia
3
Sofia
4
Sofia
5
Moscow
6
New York
7
New York
SELECT * FROM Users
WHERE City = 'Kiev'
SELECT * FROM Users
WHERE City = 'Kiev'

25. Demo
SNAPSHOT READ COMMITTED

26. SNAPSHOT







Optimistic concurrency for reads
Use row-version store in tempdb
No shared locks on reads
Doesn’t allow Dirty Reads
Doesn’t allow Non-Repeatable reads
Doesn’t allow Phantom Records
Update conflict detection

27. Demo
SNAPSHOT

28. How to avoid?
 Design database so, that it will be no
possibility for a deadlock occur 
 Modify tables in the same order
 Choose appropriate Transaction Isolation
Level and check possibility of a deadlock in
your Isolation Level
 There is no unsolvable deadlocks.. But there
can be solution, which will not suit you
completely

29. Sponsors

30. Thank you!
 Denis Reznik





Twitter: @denisreznik
Email: denisreznik@live.ru
Blog (in russian): http://reznik.uneta.com.ua
Facebook: https://www.facebook.com/denis.reznik.5
LinkedIn: http://ua.linkedin.com/pub/denis-reznik/3/502/234