Deadlocks 3.0. Final Edition. Everything that developer needs to know Denis Reznik Microsoft SQL Server MVP Director of R&D at Intapp Kyiv
Sponsors Gold Sponsors: Bronze Sponsors: Swag Sponsors:
About me Denis Reznik Kyiv, Ukraine Director of R&D at Intapp Kyiv Microsoft MVP Leader of Kyiv SQL Server User Group Co-author of “SQL Server MVP Deep Dives 2” Community Enthusiast
Agenda Locks Lock Types Lock Escalation Transaction Isolation Levels Pessimistic Optimistic Deadlocks Catching, Analyzing, Fixing
Locks
Lock Types - Shared S S S S X X
Lock Types - Exclusive X X X X S S
Lock Types - Update U U U U S S S S X X
Lock Types – Intent locks S S IS
Lock Escalation S S S S S S … S S n n = 5000 Table S S if lock can’t be put on table, process will try this every n rows 12 Buffer Pool Memory for locks S S > 24%
Lock Escalation Lock Block – 128 bytes 1 million blocks ~64 MB Escalation can be done only to Table or Partition level Escalation can be disabled for the table Trace Flag – 1224 Disable escalation based on rowcount
Transaction Isolation Levels
READ UNCOMMITTED The less restricted Isolation Level Allow all collisions, which are allowed Allow Dirty Reads Doesn’t set Shared locks on read operations
DIRTY READS IDCity 1Kiev 2Varna New York 7 IDCity 1Varna New York 7 SELECT * FROM Users WHERE City = 'Kiev' BEGIN TRAN UPDATE Users SET City = 'Varna' WHERE City = 'Kiev' SELECT * FROM Users WHERE City = 'Kiev' 0 Records ROLLBACK SELECT * FROM Users WHERE City = 'Kiev' X
READ COMMITTED Default Isolation Level Doesn’t allow Dirty Reads Shared Locks used for reads Shared locks released after the read
NO DIRTY READS IDCity 1Kiev 2Varna New York 7 IDCity 1Varna New York 7 SELECT * FROM Users WHERE City = 'Kiev' BEGIN TRAN UPDATE Users SET City = 'Varna' WHERE City = 'Kiev' SELECT * FROM Users WHERE City = 'Kiev' Wait for Shared lock on the row X S
NON-REPEATABLE READS IDCity 1Kiev 2Varna 3 4 5Tokyo 6New York 7 IDCity 1Kiev 2 3Varna 4 5Tokyo 6New York 7 BEGIN TRAN SELECT * FROM Users WHERE City = 'Varna' UPDATE Users SET City = 'Kiev' WHERE Id = 2 SELECT * FROM Users WHERE City = 'Varna' X S S... S
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
NO NON-REPEATABLE READS IDCity 1Kiev 2Varna 3 4 5Tokyo 6New York 7 IDCity 1Kiev 2 3Varna 4 5Tokyo 6New York 7 BEGIN TRAN SELECT * FROM Users WHERE City = 'Varna' UPDATE Users SET City = 'Kiev' WHERE Id = 2 SELECT * FROM Users WHERE City = 'Varna' X S S... S COMMIT
PHANTOM RECORDS IDCity 1Kiev 2Varna 3 4 5Tokyo 6New York 7 IDCity 1Kiev 2Varna Tokyo 6New York 7 BEGIN TRAN SELECT * FROM Users WHERE City = 'Varna' INSERT INTO Users VALUES (8, 'Varna') SELECT * FROM Users WHERE City = 'Varna' S S... S S
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
NO PHANTOM RECORDS IDCity 1Kiev 2Varna 3 4 5Tokyo 6New York 7 IDCity 1Kiev 2Varna Tokyo 6New York 7 BEGIN TRAN SELECT * FROM Users WHERE City = 'Varna' INSERT INTO Users VALUES (8, 'Varna') SELECT * FROM Users WHERE City = 'Varna' RANGE S-S... COMMIT
READ COMMITTED SNAPSHOT Optimistic concurrency for reads Use row-version store in tempdb No shared locks on reads Isolation rules are the same as in READ COMMITTED
READ COMMITTED SNAPSHOT IDCity 1Kiev 2Varna New York 7 IDCity 1Varna New York 7 BEGIN TRAN UPDATE Users SET City = 'Varna' WHERE City = 'Kiev' SELECT * FROM Users WHERE City = 'Kiev' SELECT * FROM Users WHERE City = 'Kiev' X tempdb IDCity 1Kiev Version Store
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
SNAPSHOT IDCity 1Kiev 2Varna New York 7 IDCity 1Varna New York 7 BEGIN TRAN UPDATE Users SET City = 'Varna' WHERE City = 'Kiev' BEGIN TRAN UPDATE Users SET City = 'London' WHERE City = 'Kiev' X tempdb IDCity 1Kiev Version Store COMMIT
Demo Deadlocks in Action
Three Rules of Deadlocks If deadlock is possible, it will occur. Deadlock should not be solved, before the real reason of it wasn’t found. There is no unsolvable deadlocks. But there can be solutions, which will not suit you completely
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 Keep transactions as small as possible Use stress-testing for your application or database
Sponsors Gold Sponsors: Bronze Sponsors: Swag Sponsors:
Thank You! Denis