Deadlocks: Lets Do One, Understand It, and Fix It

Slides & scripts: BrentOzar.com/sql/deadlocks/
Deadlocks
Let’s do one, understand it, and fix it.

99-05: dev, architect, DBA
05-08: DBA, VM, SAN admin
08-10: MCM, Quest Software
Since: consulting DBA
www.BrentOzar.com
Help@BrentOzar.com

Session agenda
Basics:
• 3 concurrency issues
• 3 ways to fix ‘em all
• 1 “fix” that makes things worse: NOLOCK
One real fix: work on tables in a consistent order
• Demo: unrealistic query
• Demo: realistic query
Using sp_BlitzLock to find the queries you need to
fix

Concurrency challenges
Locking: Lefty takes out a lock.
Blocking: Righty wants a lock, but Lefty already has it.
SQL Server will let Righty wait for forever,
and the symptom is LCK* waits.
Deadlocks:
Lefty has locks, then wants some held by Righty.
Righty has locks, then wants some held by Lefty.
SQL Server solves this one by killing somebody,
and the symptom is dead bodies everywhere.

3 ways to fix concurrency issues
1. Have enough indexes to make your queries fast,
but not so many that they slow down DUIs,
making them hold more locks for longer times.
(I cover this in Mastering Index Tuning.)
2. Tune your transactional code.
(This module focuses on this topic.)
3. Use the right isolation level for your app’s needs.
(I cover this in Mastering Server Tuning.)

1 way doesn’t fix it: dirty reads
WITH (NOLOCK):
• Ignores other people’s row locks
• Still takes out schema stability locks
(and honors other peoples’ schema locks)
SET TRANSACTION ISOLATION LEVEL READ
UNCOMMITTED
• Like putting WITH (NOLOCK) on every table

Because with dirty reads…
1. You can see data that was never committed
2. You can see rows twice
3. You can skip rows altogether
4. Your query can fail with an error:
Could not continue scan with NOLOCK due to data movement

Demoing it
If I count the number of Alexes,
and I use NOLOCK,
I get the same result every time.
As long as nothing is happening.

But while it runs…
Let’s update everyone who ISN’T Alex:
Note that I am NOT inserting or deleting rows.
Just updating the non-Alexes.

Run them both at the same
time:

That’s NOLOCK.
And that’s not a bug.
That’s what it’s
designed to do.

Sometimes, these are OK.
1. You can see data that was never committed
2. You can see rows twice
3. You can skip rows altogether
4. Your query can fail with an error:
Could not continue scan with NOLOCK due to data movement
But when they’re not OK, we have some fixes to
do.

3 ways to fix concurrency issues
1. Have enough indexes to make your queries fast,
but not so many that they slow down DUIs,
making them hold more locks for longer times.
(I cover this in Mastering Index Tuning.)
2. Tune your transactional code.
(This module explores this topic.)
3. Use the right isolation level for your app’s needs.
(I cover this in Mastering Server Tuning.)

Start SSMS with two windows.
Use Lefty.sql and Righty.sql from your resources.
In Lefty, create & populate the tables.

In Lefty, start a transaction.
Begin tran, update dbo.Lefty, but don’t commit.
The left window is now locking dbo.Lefty.

In Righty, start another.
Begin tran, update dbo.Righty, but don’t commit.
The right window is now locking dbo.Righty.

The situation so far:
Left window has:
• dbo.Lefty
exclusive lock
Right window
has:
• dbo.Righty
exclusive lock

In Lefty, update dbo.Righty.
The update starts running, but is blocked, and sits
there waiting for dbo.Righty to commit or roll back.

The situation so far:
Left window has:
• dbo.Lefty
exclusive lock
• Wants a lock
on dbo.Righty,
but can’t get it
(yet)
Right window
has:
• dbo.Righty
exclusive lock

But let’s do something terrible.
In the right hand window, don’t commit or roll
back: instead, try to get a lock on dbo.Lefty.

Things are going to happen fast.
I’ll describe what’s going to happen before I hit F5:
• The right window will want to run, but…

The situation will become:
Left window has:
• dbo.Lefty
exclusive lock
• Wants a lock on
dbo.Righty, but
can’t get it
(ever)
Right window has:
• dbo.Righty
exclusive lock
• Wants a lock on
dbo.Lefty, but
can’t get it
(ever)

Things are going to happen fast.
I’ll describe what’s going to happen before I hit F5:
• The right window will want to run, but…
• Neither side will be able to make progress
• SQL Server’s deadlock monitor wakes up every 5
seconds, and when he does, he’ll see the
problem
• He’ll pick the query that’s the easiest to roll back,
and kill it

I hit F5 in the right window,
and…
Within 5 seconds, SQL Server kills one.

The root cause: bad ordering
Left window has:
• dbo.Lefty
exclusive lock
• Wants a lock on
dbo.Righty, but
can’t get it
(ever)
Right window has:
• dbo.Righty
exclusive lock
• Wants a lock on
dbo.Lefty, but
can’t get it
(ever)

The fix: better ordering
If we work on tables in a consistent order:
• Always update dbo.Lefty first,
then update dbo.Righty
Or:
• Always update dbo.Righty first,
then update dbo.Lefty
We’ll be fine either way, as long as we’re
consistent.

Trying it:
I set up both windows to work on dbo.Lefty first.
I hit execute in the left window first, then the right:

This sounds bad at first.
We have a new problem: blocking.
The right window can’t make progress.
But that’s actually good:
he can’t grab a lock that would block others.
The left side is able to keep right on going.

Continuing in the left window…

Continuing in the left window…
When the left finally commits, the right is free to
start making progress, and can’t be blocked by the
left.

The moral of the story
Work in tables in a consistent order, like:
• Always parents, then children
• Or always children, then parents
Which one you choose is less important
than being ruthlessly consistent.
If even one query works out of order,
there will be deadlocks.

Session agenda
Basics:
• 3 concurrency issues
• 3 ways to fix ‘em all
• 1 “fix” that makes things worse: NOLOCK
One real fix: work on tables in a consistent order
• Demo: unrealistic query
• Demo: realistic query
Using sp_BlitzLock to find the queries you need to
fix
We are here.

Real-world scenario
At Stack Overflow, you can up/downvote questions.
Voting

What happens when you vote
Update your Users.LastAccessDate column to show
that you’ve been accessing the site
Insert a row in the Votes table
Add one point to the question’s score
(by updating its row in Posts (Q&A))
Add one point to the question-asker’s reputation
(by updating their row in Users, set Reputation +
1)

How it goes wrong
What if these two happen at the exact same time:
User A upvotes a question
owned by UserB
UserB upvotes a question
owned by UserA

Just for this demo

Start these two at the same time
And one will always lose. (Which one? Tough to
tell.)

First, we lock our own row
Last, we try to lock someone
else’s

Will ordering help?
What if we move all the user updates to the top?
Just for this demo

Still screwed.
It’s not enough to lock tables in the same order:
we also need to touch them as few times as
practical.

Could we update both users at once?
How might we solve this problem?

Ways to fix it
“Just remove the waitfor” = “make it all faster”
• Get faster hardware
• Tune indexes on the underlying tables
• Don’t hold transactions open on the app side
Try merging both Users updates into a single query
(where it’s the Voter, OR it’s the question-owner)
Do the LastAccessDate update outside of the
transaction (does it really matter?)

It works though! No deadlocks.
Well, kinda: there’s a catch. Notice the runtimes.

The longer it takes before others can start
work.

Another
approach
Do we really need
your Last Access
Date to be part of
the transaction?

Run ‘em both at the same time…
No deadlocks, AND they both finish in 10 seconds!

The more you fix, the faster it
goes
“Just remove the waitfor” = “make it all faster”
• Get faster hardware
• Tune indexes on the underlying tables
• Don’t hold transactions open on the app side
Try merging both Users updates into a single query
(where it’s the Voter, OR it’s the question-owner)
Do the LastAccessDate update outside of the
transaction (does it really matter?)

sp_BlitzLock helps you spot ‘em.
Thanks to SQL 2012 or newer, the default system
health Extended Events session, and Erik Darling:

Top result set: list of deadlocks
Scroll to the far right, and you also get the
deadlock graph. Save it as an XDL file, then re-
open it in SSMS or in SentryOne Plan Explorer.

Bottom results: analytics
This is what really helps me get to the bottom of it:

Bottom results: analytics
Tables & indexes: use my D.E.A.T.H. Method on
‘em
Queries: hit tables in a consistent order, tune txns

Deadlocks: Lets Do One, Understand It, and Fix It

More Related Content

What's hot (7)

Similar to Deadlocks: Lets Do One, Understand It, and Fix It (20)

More from Brent Ozar (16)

Recently uploaded (20)

Deadlocks: Lets Do One, Understand It, and Fix It