SqlSaturday199 - Deadlocks

  • 250 views
Uploaded 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 …

"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.

More in: Technology , Travel , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
250
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
3
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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