Blocking Analysis is the live lock-contention investigation module. It combines blocking-chain discovery, head-blocker ranking, application-captured timeline history, kill-safety signals, and detailed session inspection so the operator can identify the true root blocker before acting.
It works best beside Wait Statistics when waits suggest lock pressure, and Query Statistics when you need plan and query evidence behind the blocking session.
- Detect active blocking chains and isolate head blockers.
- Switch between graph, tree, timeline, and compact blocker-list views.
- Inspect SQL text, lock details, impact estimates, and recurrence history for any session.
- Export incident evidence to CSV, Markdown, HTML, audit, and history artifacts.
- Review safety context before killing a session.
- Top action bar with refresh and export controls
- Severity banner and quick blocker summary
- Main analysis tabs for Graph, Tree, Timeline, Details, Alerts, and Filter
- Right-side Session Inspector with SQL, Locks, Impact, and History tabs
- Footer metrics showing blocked sessions, chain count, max wait, and total wait
Read the colored banner first. It tells you whether the latest snapshot is idle, warning-level, or critical, and it summarizes the current distribution of low, medium, high, and critical sessions.
The graph answers who is blocking whom, how deep the chain goes, and whether a single root session is creating a broad outage.
Tree view gives the sortable session table with wait type, wait time, depth, database, login, and host values needed for operational triage.
The inspector is where SQL text, lock details, impact estimates, and recurrence evidence are combined into a decision about escalation or session termination.
Severity Banner, Graph View, and Live Incident Shape
This is the fastest triage view. The banner announces whether the current snapshot is critical, while the graph shows the head blocker, downstream sessions, and approximate wait progression inside the chain. Use this view first when the operator needs an immediate picture of blast radius.
Tree View for Exact Session Hierarchy
Tree view turns the incident into an exact hierarchy table. This is where you verify SPID, wait type, wait time, depth, database, login, and host information without losing the chain relationship. It is usually the best view for operator handoff or ticket evidence.
Timeline View for Recurrence and Trend Direction
Timeline view uses application-captured snapshots rather than a built-in SQL Server blocking history. It answers whether the incident is a short spike or a recurring pattern by showing snapshots, total wait, chain depth, and kill markers across recent collection windows.
- Auto-Refresh toggles 5-second live refresh while the view is visible
- Refresh Now triggers an immediate blocking snapshot
- Export CSV, Report, Audit CSV, and History CSV export the current incident or the captured history
- AI Brief summarizes the current state in readable plain language
- Database, User, Application, and Severity narrow the visible blocking set
- Min Wait and Max Wait trim low-value noise or extreme outliers
- Critical Only, Production DB, and Head Blockers act as quick triage shortcuts
- Saved filters restore repeat investigation presets for common incidents
- DB contains scopes notifications to production-like database names
- Min Severity and Min Chain avoid low-signal noise
- Cooldown prevents repeated alerts for the same condition
- Webhook settings let the operator forward blocking evidence to team channels
- Low: wait below 5 seconds
- Medium: 5 to 30 seconds
- High: 30 to 60 seconds
- Critical: 60 seconds or higher
Compact Head-Blocker List
The Details tab is the short blocker roster. It is useful when you need to rank active blockers quickly without reading the full graph or tree. The blocked-count and CPU columns help distinguish a low-cost nuisance block from an expensive operational root cause.
Filter and Webhook Configuration
The Filter tab combines visibility controls and outbound notification setup. Teams can save repeat filters, trim low-wait noise, and forward findings detected during an active desktop session. This is not a persistent background alerting service.
Smart Alerts and Noise Control
Current-session alert rules reduce noise while the investigation view is active. Operators can scope by database token, require a minimum severity, insist on a minimum chain count, and enforce a cooldown. They do not collect or evaluate blocking while the desktop application is closed.
Shows the selected session identity, wait type, severity, current SQL text, and request context. This is the first place to confirm whether the session is a blocking writer, a long transaction, or a downstream victim.
Groups lock evidence by resource type, mode, status, resource, and count. It helps explain whether the blocker is holding broad object or page locks versus a narrower key-level conflict.
Estimates directly affected sessions, aggregate impacted wait, and a rough stabilization window. Treat it as triage guidance rather than a guarantee of rollback or recovery cost.
Shows recurrence evidence captured by the application, including first seen, last seen, occurrence count, and peak wait. This is useful for deciding whether the incident is operationally normal or becoming chronic.
SQL and Session Summary
The SQL tab links the selected SPID to its current request context, login, host, program, severity, and SQL text. Use it to confirm whether the blocking command is an expected maintenance task, an application transaction, or a session that should not be terminated casually.
Lock Evidence
The Locks tab surfaces the exact lock footprint of the selected session. Waiting versus granted states, plus resource granularity, are especially useful when two sessions appear similar but only one is truly holding the contested resource.
Impact Analysis
Impact view turns a blocking SPID into an operational estimate. It summarizes directly affected sessions, peak and aggregate impacted wait, and a heuristic stabilization window so the operator can compare intervention benefit against risk.
Recurring Blocker History
History view is the recurrence check. If the same SPID pattern or principal keeps appearing with rising peak waits, the problem is likely architectural or workflow-driven rather than a one-off operator mistake.
- sys.dm_exec_requests
- sys.dm_exec_sessions
- sys.dm_tran_locks
- sys.dm_exec_sql_text(...)
- sys.dm_exec_query_plan(...)
- BlockingView renders the UI, tabs, and operator actions.
- BlockingService builds chains, severity, history, alerts, and reports.
- BlockingRepository and BlockingQueries collect the SQL evidence.
- BlockingNotificationWorker handles background notification polling.
- Auto-refresh runs every 5 seconds when enabled and visible.
- No active database connection disables periodic refresh.
- Timeline and recurrence depend on snapshots captured by the desktop app, not by SQL Server itself.
- Graph and tree answer chain structure.
- Inspector answers session safety and actionability.
- Timeline answers recurrence and trend.
- Alert and webhook flows answer operational visibility outside the module.
Visitors can download the exported blocking report artifacts directly. The HTML version is easier to share with managers or teammates, while the Markdown version preserves the raw exported structure for deeper review or version control.
Blocking Incident Report
HTML export for stakeholder sharing with incident summary, blocker chain, session evidence, and operator notes.
- Open Blocking Analysis, keep Auto-Refresh on, and read the severity banner before filtering anything.
- Use Graph to understand the chain shape, then Tree to validate the exact root and downstream sessions.
- Select the suspected blocker and review SQL, Locks, Impact, and History in the Session Inspector.
- Check Timeline when you need to know whether the blocker is recurring or only a transient event.
- Export HTML or Markdown evidence before intervention if the incident may need handoff or audit traceability.
- Kill a session only after the SQL text, lock pattern, and impact estimate all support that action.
- One head blocker with many affected sessions usually means the incident is concentrated and action on one SPID can relieve a broad backlog.
- High Max Wait plus high Total Wait means the problem is both severe for individual sessions and expensive overall.
- Rising chain depth indicates cascading contention rather than a simple two-session block.
- The Session Inspector is the safety gate: read SQL, lock state, impact, and recurrence together before deciding to kill anything.
- The module is an investigation surface, not an auto-remediation engine.
- Safe-to-kill style signals are heuristics and still require operator judgment.
- Production DB filtering is a name heuristic, not a formal environment label.
- History quality depends on whether the desktop app was collecting snapshots during the incident window.