Blocking

Category: Blocking & Deadlocks · Also known as: Top Blocker

One session is holding locks that other sessions are stuck waiting behind, forming a chain. Everyone downstream is idle until it clears.

What this finding means

One session held locks that other sessions were waiting behind, forming a chain. WISdom reconstructs the full chain, identifies the session at its root, and reports how many sessions were queued behind it and how deep the chain went. Depth matters as much as width: a chain three levels deep means blocked sessions are themselves blocking others.

Why it matters

Blocking is idle time that looks like slowness. Every session in the chain is doing nothing while holding its own locks and its own connection, so the impact compounds down the chain. Unlike a slow query, blocking usually resolves itself, which is exactly why it goes unfixed and recurs: nothing alerts, and the same head blocker returns the next day.

How WISdom detects it

blocking_session_id in sys.dm_exec_requests is followed to the root of each wait chain and the sessions behind it are counted, with LCK_* wait types and wait times attached and head session detail from sys.dm_exec_sessions. The chain is compared to the same head blocker in the 15 minutes either side of this minute-of-day over four weeks.


Collected from	sys.dm_exec_requests.blocking_session_id (reconstruct the chain) + LCK_* wait_type / wait_time; head detail from sys.dm_exec_sessions.
Compared with	Same blocker during 15 minutes before and 15 minutes after of the same minute in the past 4 weeks
Related screen	Blocking Details

How it is scored

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

How to read the numbers

Head session is the only session that matters for the fix; everything else in the chain is a symptom. Sessions blocked measures width and Chain depth measures cascade. Max wait is the longest single wait in the chain and is the closest thing to the user-visible delay. Read the chain top down: commit or clear the head and everything below drains.

What normally causes it

A transaction opened before external work, an API call, a file write, or a user prompt, and committed after it returns.
A long-running write, a bulk update or a maintenance operation, holding locks across a large row range.
Lock escalation converting many row locks into a table lock, widening the blast radius.
Readers under a default isolation level queueing behind writers on rows they only need to read.

What this finding is not

Not a deadlock. Blocking clears on its own once the head commits. A deadlock is a cycle that SQL Server has to break by killing a victim. Different finding, different fix.
Not always a problem. Short blocking is normal and healthy in any concurrent system. Depth, duration, and recurrence are what make it a finding.
Not necessarily the head session’s fault. The head is often a well-behaved statement made slow by something else, such as storage latency. Check whether the head is itself waiting.

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. Shorten the head session’s transaction

The head holds the locks everything else waits on. Almost every case is a transaction opened before external work, an API call or a file write, and committed after. Move that work outside the transaction.

2. Clear the chain that is running now

Commit or kill the head session and the chain drains immediately. This buys time; it does not stop it happening again.

3. Move readers off the writers’ path

If readers keep queueing behind writers, row-versioning isolation lets them read without waiting. Test it first, it changes tempdb behaviour.