Deadlock

Category: Blocking & Deadlocks · Also known as: Top Deadlock Chain

Two or more transactions blocked each other in a cycle, so SQL Server killed one to break it. The victim’s work was rolled back.

What this finding means

Two or more transactions blocked each other in a cycle that could not resolve, so SQL Server chose a victim and rolled its transaction back. WISdom reports the deadlock group, which sessions took part, which objects were contested, and how many times the same cycle recurred in the range.

Why it matters

Deadlocks are the one contention finding that fails work outright rather than slowing it. The victim’s transaction is rolled back, and unless the application handles the error, that is a lost order, a failed save, or an error page. The fix is also unusually durable: aligning lock order removes the cycle permanently rather than reducing its probability.

How WISdom detects it

Deadlock detail comes from the deadlock graph captured by the system_health Extended Events session, read as XDL. This is the one finding that cannot be built from point-in-time DMV data, so it requires the deadlock feed to be enabled. Groups are compared to the same deadlock group in the 15 minutes either side of this minute-of-day over four weeks.


Collected from	Deadlock capture - system_health Extended Events / deadlock graph (XDL). NOT available from the point-in-time DMVs; requires the deadlock feed. [needs new feed]
Compared with	Same deadlock group during 15 minutes before and 15 minutes after of the same minute in the past 4 weeks
Related screen	Deadlocks Detalis

How it is scored

This rule fires only when the condition is met. It contributes an incident score of 1 when the finding is present, 2 when it exceeds its four-week maximum, and 3 when it has never been seen before.

How to read the numbers

Victims is the count of transactions actually rolled back and is the real business impact. Objects names the contested resources, and where two objects appear in opposite order on each side you are looking at the classic lock-order cycle. Occurrences across the range is the field that separates a one-off from a pattern worth engineering time.

What normally causes it

Two code paths touching the same two objects in opposite order.
A non-clustered index and its base table accessed in different sequences by an update and a read.
Lock escalation widening one transaction’s footprint until it overlaps another’s.
Long transactions holding locks long enough for an overlap that would otherwise never occur.

What this finding is not

Not the same as blocking. Blocking is a queue that drains. A deadlock is a cycle that cannot drain, which is why SQL Server intervenes.
Not fixed by retrying. Retry handling stops users seeing errors, and it is worth having, but the cycle is still there and still costing rolled-back work.
Not visible without the Extended Events feed. If the deadlock feed is off, this finding cannot fire, and its absence is not evidence that deadlocks are not happening.

What are some possible resolutions?

The options below are ranked. Option 1 fixes the cause where it lives and costs nothing; option 3 spends money or escalates, so try it last.

1. Align the lock order on both sides

Both statements touch the same objects in opposite order. Make them take locks in the same sequence and the cycle cannot form. This is the actual fix.

2. Shrink the lock footprint

Shorter transactions and a covering index mean each side holds fewer locks for less time, which closes the window where they can collide.

3. Retry the victim transaction

Deadlocks that cannot be designed out should not fail user work. Catch the deadlock error and retry. Containment, not prevention.