Everything you ever wanted to ask but were too shy

Slides:



Advertisements
Similar presentations
Chapter 16 Concurrency. Topics in this Chapter Three Concurrency Problems Locking Deadlock Serializability Isolation Levels Intent Locking Dropping ACID.
Advertisements

1 Lecture 11: Transactions: Concurrency. 2 Overview Transactions Concurrency Control Locking Transactions in SQL.
Accessing data Transactions. Agenda Questions from last class? Transactions concurrency Locking rollback.
1 Data Concurrency David Konopnicki 1997 Revised by Mordo Shalom 2004.
Module 15: Managing Transactions and Locks. Overview Introduction to Transactions and Locks Managing Transactions SQL Server Locking Managing Locks.
Security and Transaction Management Pertemuan 8 Matakuliah: T0413/Current Popular IT II Tahun: 2007.
Database Administration Part 1 Chapter Six CSCI260 Database Applications.
Managing Transaction and Lock Vu Tuyet Trinh Hanoi University of Technology 1.
Transactions and Exception Handling Eric Allsop SQLBits 6 th October 2007.
1099 Why Use InterBase? Bill Todd The Database Group, Inc.
1cs Intersection of Concurrent Accesses A fundamental property of Web sites: Concurrent accesses by multiple users Concurrent accesses intersect.
Concurrency and Transaction Processing. Concurrency models 1. Pessimistic –avoids conflicts by acquiring locks on data that is being read, so no other.
Unit 9 Transaction Processing. Key Concepts Distributed databases and DDBMS Distributed database advantages. Distributed database disadvantages Using.
IN-MEMORY OLTP By Manohar Punna SQL Server Geeks – Regional Mentor, Hyderabad Blogger, Speaker.
Transactions and Locks A Quick Reference and Summary BIT 275.
Random Logic l Forum.NET l Transaction Isolation Levels Forum.NET Meeting ● Nov
SQL Server 2005 Engine Optimistic Concurrency Tony Rogerson, SQL Server MVP Independent Consultant 26 th.
Giovanni Chierico | May 2012 | Дубна Data Concurrency, Consistency and Integrity.
SQLintersection Understanding Transaction Isolation Levels Randy Knight Wednesday, 3:45-5:00.
Module 11: Managing Transactions and Locks
Module 14: Managing Transactions and Locks. Overview Introducing Transactions and Locks Managing Transactions Understanding SQL Server Locking Architecture.
What is Data Science and Who is Data Scientist
In this session, you will learn to: Implement triggers Implement transactions Objectives.
Deadlocks 3.0. Final Edition. Everything that developer needs to know Denis Reznik Microsoft SQL Server MVP Director of R&D at Intapp Kyiv.
SQL Server Deep Dive Denis Reznik Data Architect at Intapp.
Does the Optimistic Concurrency resolve your blocking problems Margarita Naumova, SQL Master Academy.
Delete Data Database Administration Fundamentals LESSON 3.4.
Locks, Blocks & Isolation Oh My!. About Me Keith Tate Data Professional for over 14 Years MCITP in both DBA and Dev tracks
Read Dirty to Me: SQL Server Isolation Levels Wendy Pastrick Arrow IT Consulting.
SQLintersection Locks, Blocks, and Deadlocks Oh My! Randy Knight Wednesday, 2:15-3:15.
Database Transactions  Transaction Management and Concurrency Control.
SQL Server Performance Tuning
Denis Reznik Data Architect, Intapp, Inc. Microsoft Data Platform MVP
Thank You! #sqlsatdnipro Denis
Let Me Finish... Isolating Write Operations
Solving the Hard Problems
LAB: Web-scale Data Management on a Cloud
Isolation Levels Understanding Transaction Temper Tantrums
Let Me Finish... Isolating Write Operations
Let Me Finish... Isolating Write Operations
Query Execution Expectation-Reality Denis Reznik
It’s Always a Hard Choice
Batches, Transactions, & Errors
SQL Server 2014 Hidden Treasures Denis Reznik Microsoft SQL Server MVP
Hidden Gems of SQL Server 2014
Hidden gems of SQL Server 2016
මොඩියුල විශ්ලේෂණය Transactions කළමනාකරණය.
Transactions, Locking and Query Optimisation
SQL Server Performance Tuning Nowadays
Hidden Gems of SQL Server 2016
Understanding Transaction Isolation Levels
Let Me Finish... Isolating Write Operations
Batches, Transactions, & Errors
Hidden Gems of SQL Server 2014
Let Me Finish... Isolating Write Operations
Locks, Blocks, Deadlocks
Transactions and Concurrency
Deadlocks Everything you ever wanted to ask but were too shy
Sioux Falls, SD | Hosted by (605) SQL
Hidden Gems of SQL Server 2014
A Masters view on Locking and blocking
Hidden Gems of SQL Server 2014
About Wolf DBA for over 19 years At RDX for nearly 9
Denis Reznik SQL Server 2017 Hidden Gems.
Isolation Levels Understanding Transaction Temper Tantrums
Why should I care about SQL, if I have ORM?
Module 13: Creating Highly Concurrent SQL Server 2012 Applications
A Masters view on Locking and blocking
Denis Reznik SQL Server 2017 Hidden Gems.
A Masters view on Locking and blocking
Presentation transcript:

Everything you ever wanted to ask but were too shy Deadlocks Everything you ever wanted to ask but were too shy Denis Reznik Data Architect at Intapp, Inc. Microsoft Data Platform MVP

About me Denis Reznik Kyiv, Ukraine Data Architect at Intapp, Inc. Microsoft Data Platform MVP Co-Founder of Ukrainian Data Community Kyiv PASS Regional Mentor, CEE Co-author of “SQL Server MVP Deep Dives 2”

Agenda Classic Deadlock Common Deadlock When Deadlock Graph doesn’t Make Sense Object Deadlock Range Deadlock Implicit Deadlock Hidden Deadlock NOLOCK Deadlock One Query Deadlock Undetectable Deadlock

Classic Deadlock DEADLOCK! wait wait ID City 1 Kyiv 2 Ljubljana 3 BEGIN TRAN UPDATE Users SET CityId = 2 WHERE Id = 4 UPDATE City SET Name = 'Dnipro' WHERE Id = 3 BEGIN TRAN UPDATE City SET Name = 'Dnipro' WHERE Id = 3 UPDATE Users SET CityId = 2 WHERE Id = 4 ID City 1 Kyiv 2 Ljubljana 3 Dnipropetrovsk X wait wait ID User City_Id 1 Dejan Sarka 2 Mladen Prajdic 3 Matija Lah 4 John Smith X

How to Deal with the Deadlock? Catch the Deadlock Find the Root Cause Fix the Deadlock

Demo Common Deadlock

Lock Types - Shared X S S

Lock Types - Exclusive S X X

Deadlocks. When Graph does not make sense. Demo Deadlocks. When Graph does not make sense.

Lock Types - Update s U U X S U X X U

Return different results so they are non-repeatable NON-REPEATABLE READS BEGIN TRAN SELECT * FROM Users WHERE City = 'Ljubljana' ID City 1 Kyiv 2 Ljubljana 3 4 5 Tokyo 6 New York 7 ID City 1 Kyiv 2 3 Ljubljana 4 5 Tokyo 6 New York 7 UPDATE Users SET City = 'Kyiv' WHERE Id = 2 X S Return different results so they are non-repeatable S ... S SELECT * FROM Users WHERE City = 'Ljubljana'

REPEATABLE READ ID City 1 Kyiv 2 Ljubljana 3 4 5 Tokyo 6 New York 7 ID BEGIN TRAN SELECT * FROM Users WHERE City = 'Ljubljana' ID City 1 Kyiv 2 Ljubljana 3 4 5 Tokyo 6 New York 7 ID City 1 Kyiv 2 3 Ljubljana 4 5 Tokyo 6 New York 7 UPDATE Users SET City = 'Kyiv' WHERE Id = 2 X S S ... S SELECT * FROM Users WHERE City = 'Ljubljana' COMMIT

Demo Object Deadlock

Lock Escalation … >= 25% 1 2 Table S S Buffer Pool n = 5000 Memory for locks 1 S >= 25% 2 S … 3 S n S n = 5000 if lock can’t be put on table, process will try this every n + 1250 rows

Lock Types – Intent locks IS IS S

Demo Range Deadlock

PHANTOM RECORDS Phantom Record ID City 1 Kyiv 2 Ljubljana 3 4 5 Tokyo BEGIN TRAN SELECT * FROM Users WHERE City = 'Ljubljana' ID City 1 Kyiv 2 Ljubljana 3 4 5 Tokyo 6 New York 7 ID City 1 Kyiv 2 Ljubljana 3 4 8 5 Tokyo 6 New York 7 INSERT INTO Users VALUES (8, 'Ljubljana') S S ... S S SELECT * FROM Users WHERE City = 'Ljubljana' Phantom Record

SERIALIZABLE ID City 1 Kyiv 2 Ljubljana 3 4 8 5 Tokyo 6 New York 7 ID BEGIN TRAN SELECT * FROM Users WHERE City = 'Ljubljana' ID City 1 Kyiv 2 Ljubljana 3 4 8 5 Tokyo 6 New York 7 ID City 1 Kyiv 2 Ljubljana 3 4 5 Tokyo 6 New York 7 INSERT INTO Users VALUES (8, 'Ljubljana') RANGE S-S ... SELECT * FROM Users WHERE City = 'Ljubljana' COMMIT

Demo Range Deadlock

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

SNAPSHOT ID City 1 Ljubljana 2 3 4 5 6 New York 7 ID City 1 Kyiv 2 BEGIN TRAN UPDATE Users SET City = 'Ljubljana' WHERE City = 'Kyiv' BEGIN TRAN UPDATE Users SET City = 'London' WHERE City = 'Kyiv' X COMMIT Version Store ID City 1 Kyiv tempdb

Demo Implicit Deadlock

READ UNCOMMITTED (NOLOCK) SELECT * FROM Users WHERE City = 'Kyiv' ID City 1 Kyiv 2 Ljubljana 3 4 5 6 7 ID City 1 Kyiv 2 Ljubljana 3 4 5 6 New York 7 BEGIN TRAN UPDATE Users SET City = 'Kyiv' WHERE City = 'New York' SELECT * FROM Users WHERE City = 'Kyiv' ROLLBACK Dirty Read X X SELECT * FROM Users WHERE City = 'Kyiv'

Demo NOLOCK Deadlock

Three Rules of Deadlocks If deadlock is possible, it will occur. Deadlock should not be solved, before the root cause of it wasn’t found. There are no unsolvable deadlocks. But there can be solutions, which will not suit you completely 25 |

How to Avoid? Design database so, that it will be no possibility for a deadlock occur Ha-ha-ha  Modify tables in the same order Choose appropriate Transaction Isolation Level Consider optimistic ones Keep transactions as small as possible Use stress-testing for your application or database 26 |

Thank You! Denis Reznik Twitter: @denisreznik Email: denisreznik@gmail.com Blog: http://reznik.uneta.com.ua Facebook: https://www.facebook.com/denis.reznik.5 LinkedIn: http://ua.linkedin.com/pub/denis-reznik/3/502/234