When users report that an application has stopped responding, a SQL Server blocking chain can provide an immediate explanation.
One session is waiting for another. More sessions may be waiting behind it. At the top of that chain is the head blocker.
Finding that session matters. During an active incident, it helps assess which workload is affecting the system and whether intervention may be necessary.
It does not yet explain why normal transaction processing developed into a production problem.
SQL Server blocking does not automatically mean something is broken
SQL Server coordinates concurrent access through locks and, depending on the isolation model, row versioning. Blocking occurs when one session holds a lock and another session requests an incompatible lock on the same resource. Microsoft provides a detailed technical guide to understanding and resolving SQL Server blocking.
That is normal transaction behaviour. A database system must protect data consistency while work is in progress.
The operational question is not whether blocking exists. It is whether sessions wait long enough to affect users, scheduled processing, batch completion, or dependent workloads.
A brief wait between two transactions may be harmless. The same locking relationship becomes a problem when the transaction remains open, the number of waiting sessions grows, or a time-sensitive process cannot continue. This wider relationship between SQL Server blocking and concurrency is easy to miss when infrastructure metrics still appear normal.
The blocking chain describes the current dependency. It does not explain why that dependency lasted long enough to matter.
What the head blocker can and cannot tell you
The head blocker is the session at the top of the active blocking chain. Other requests are waiting directly or indirectly for resources held by that session.
During an incident, I treat that as an operational fact. I want to understand what the session is doing, how many requests are affected, how long they have been waiting, and whether the impact is still growing. Current request information, including the blocking session and wait details, is available through sys.dm_exec_requests.
That information helps me decide whether I need to protect a critical workload or restore service.
I would not treat the head blocker as the root cause based on that information alone.
The session may be running an expected application transaction. It may be idle while an earlier statement has left a transaction open. The work may take longer than usual because more data is involved, the execution plan has changed, or another process now overlaps with it.
The blocking chain does not distinguish between those situations. It shows where the waiting begins, not what caused the transaction to hold locks for that length of time.
Transaction duration and timing often matter more than the session ID
A session does not have to execute incorrect SQL to cause serious blocking.
An application can begin a transaction, perform database work, and then wait for additional processing before committing. A large update may be legitimate but hold locks longer than the surrounding workload can tolerate. A query may read or modify more data than expected because its access path has changed.
Timing can be just as important.
Two processes may run without conflict for months when they execute at different times. A schedule change, increased data volume, a slower upstream process, or a longer-running batch can make them overlap.
Reporting workloads can become part of the same concurrency problem. For example, Power BI workloads using SQL Server may compete with transactional or batch activity when queries overlap, potentially making the impact visible first as slow reports rather than as an obvious database problem.
Neither process has to be new. The workload relationship has changed.
That is why I would not change an index, isolation level, application query, or SQL Server setting based only on a snapshot of the blocking chain. The same principle applies throughout SQL Server bottleneck triage: the first visible signal needs to be tested against workload and runtime context before it becomes the basis for a change.
Before changing the system, the investigation needs to explain what kept the transaction open and why competing work reached the same resources at that moment.
Historical context matters when the blocking has already ended
A reliable SQL Server blocking analysis needs more than the current session ID. Current session and transaction data can describe what is happening now. If the issue has already ended or only appears at certain times, historical evidence becomes more important. As discussed in SQL Server Monitoring Is Not Diagnosis, recorded data creates visibility, but the interpretation still depends on workload and operational context.
Extended Events or monitoring data may preserve the blocking relationship itself. Application logs, job history, and deployment timelines can help reconstruct the surrounding events. Query Store can add execution-plan and runtime context, but it does not record the blocking chain.
The relevant evidence depends on the situation. The investigation may need to determine whether a transaction remained open while the application waited for another service, whether a batch started earlier than usual, or whether a plan or data-volume change extended the runtime enough to create an overlap.
Not every incident requires every data source. It requires enough evidence to explain the duration and timing before a permanent change is made.
Incident response and root-cause analysis are different tasks
Production pressure often forces a decision before the full cause is known.
Terminating the head blocker may restore service. It also aborts the transaction and starts a rollback. Depending on the amount of work already completed, that rollback can take time and may continue to hold resources while SQL Server reverses the changes.
Leaving the session running avoids that immediate rollback but may extend the impact on waiting processes.
There is no universal answer. The decision depends on the importance of the blocking transaction, the number and criticality of affected sessions, whether the work is still progressing, and the likely operational effect of a rollback.
That is incident response.
Root-cause analysis begins once the immediate pressure is under control. It asks what should change so that the same workload pattern does not create the same impact again.
The distinction matters. An emergency termination does not prove that the session or query was badly designed. Restoring service also does not mean that the underlying problem has been resolved.
What should be reviewed before changing the system
The evidence may point to different parts of the environment.
A transaction may need to be shorter or split into smaller units. A query may need a better access path. Two scheduled processes may need different execution windows. An application may hold a transaction open while it performs work that belongs outside the transaction.
In other cases, the locking behaviour is expected but the isolation model no longer fits the workload. That is an architectural decision and should not be made during an incident.
The most useful correction may not be a database change at all. The application workflow, batch design, scheduling, or monitoring may need adjustment.
Application timeouts may also require review when they do not match the expected processing time. Increasing a timeout does not remove the blocking and cannot replace an understanding of the underlying workload.
The head blocker remains important because it shows where the active wait begins. It may provide enough information to decide whether immediate action is required.
It is not enough to decide what should be changed permanently.
For that, the transaction duration, query behaviour, workload overlap, and timeline still have to explain why ordinary locking became a production issue.
Foto von Se. Tsuchiya auf Unsplash
