SqlSaturday199 - Deadlocks

686 views

Published on

"Deadlock" is a terrible word, isn't it? Is it as scary as it sounds? Why do they occur and how can they affect an application? Significantly important question is how to solve "Deadlock" issues? The answers to these questions can be found in my session, which is completely dedicated to the fundamental principles of locking and isolation levels.

Published in: Technology, Travel, Business
  • Be the first to comment

SqlSaturday199 - Deadlocks

  1. 1. Deadlock detected! All is lost or it's too early to sound the alarm? Denis Reznik
  2. 2. Sponsors
  3. 3. About me      3 | Denis Reznik Kiev, Ukraine Database Architect at The Frayman Group Microsoft MVP Community enthusiast
  4. 4. Agenda  Locks  Lock Types  Transaction Isolation Levels  Deadlocks  Classic Deadlocks  Not obvious deadlocks  Deadlock detecting and analyzing
  5. 5. Lock Types- Shared X S S
  6. 6. Lock Types - Exclusive S X X
  7. 7. Lock Types - Update S U X U S
  8. 8. Lock Types – Intent locks IS S IS
  9. 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. 10. Demo READ UNCOMMITTED
  11. 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. 12. READ COMMITTED  Default Isolation Level  Doesn’t allow Dirty Reads  Shared locks released after the read
  13. 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. 14. Demo READ COMMITTED
  15. 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. 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. 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. 18. Demo REPEATABLE READ
  19. 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. 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. 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. 22. Demo SERIALIZABLE
  23. 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. 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. 25. Demo SNAPSHOT READ COMMITTED
  26. 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. 27. Demo SNAPSHOT
  28. 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. 29. Sponsors
  30. 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

×