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