Sqldeadlock Review

SQL Server Deadlock Analysis Skill

Purpose

Parse a SQL Server deadlock XML graph, identify the victim and winner processes, extract the queries and lock acquisition patterns involved, match against 17 known deadlock patterns (P1–P17), and produce a prioritized remediation plan.

Input

Accept any of:

• Raw `` XML (from system_health XE session or SSMS deadlock graph Save As XML)
• A file path to a .xdl or .xml deadlock graph file
• A description of the deadlock if XML is not available

How to Run

1. Parse the XML structure
2. Extract process list (victim, winner, their queries, lock waits)
3. Extract resource list (what locks are held and requested)
4. Match against pattern library
5. Generate remediation recommendations

---

XML Structure Reference

  
    
  
  
    
      
        
          UPDATE Orders SET Status = 1 WHERE Id = @id
        
      
      UPDATE Orders SET Status = 1 WHERE Id = @id
    
    ...
  
  
    
      
        
      
      
        
      
    
    ...
  

---

Extraction Checklist

For each process:

• Process ID, SPID, victim status (yes/no)
• Query text (from ` and `)
• waitresource — what lock it is waiting for
• transactionname — the transaction context
• isolationlevel — READ COMMITTED, SNAPSHOT, SERIALIZABLE, etc.
• logused — how much log has been written (indicator of transaction size)

For each resource:

• Resource type: keylock, pagelock, objectlock, ridlock, metadatalock
• Object and index name
• Mode held by each owner (S, U, X, IS, IX, SIX)
• Mode requested by each waiter

---

Pattern Library (P1–P17)

P1 — Classic Forward/Reverse Access Order

• Signature: Process A holds X on resource R1, waits for resource R2. Process B holds X on R2, waits for R1.
• Severity: High
• Cause: Two transactions update the same pair of rows in opposite order.
• Fix: Enforce a consistent access order in application code (always update table A before table B, always process rows in ascending PK order).

P2 — Reader/Writer Deadlock (Shared vs Exclusive)

• Signature: Process A holds S lock (SELECT), waits for X. Process B holds X (UPDATE), waits for S to be released.
• Severity: High
• Cause: A long-running read transaction blocks a writer; another reader prevents the writer from completing, causing a cycle.
• Fix: Enable READCOMMITTEDSNAPSHOT isolation (ALTER DATABASE ... SET READ_COMMITTED_SNAPSHOT ON). Readers take no shared locks under RCSI — the most common fix for reader/writer deadlocks without changing application code.

P3 — Update Lock Escalation Deadlock

• Signature: Multiple processes hold U locks on different rows, each waiting for U on the other's row.
• Severity: High
• Cause: UPDATE statements taking U locks in different orders on the same table.
• Fix: Add an index on the WHERE clause columns so each update targets exactly one row (reduces lock scope). Consider using WITH (ROWLOCK) hint. Consistent access order also applies.

P4 — Missing Index Causing Scan-Level Page or Table Lock Deadlock

• Signature: objectlock or pagelock resource type (not keylock) in the resource list.
• Severity: High
• Cause: Without a suitable index, SQL Server may scan pages and acquire page or table locks directly. Multiple transactions competing for the same page or table deadlock each other.
• Fix: Add a nonclustered index on the filter column so SQL Server can seek to specific rows and take row-level (keylock) locks instead of page or table locks. Use the sqlindex-advisor skill if an execution plan is available.

P5 — Bookmark Lookup Deadlock (Key Lookup)

• Signature: Two keylock resources: one on a nonclustered index, one on the clustered index (PK). Process A holds lock on NC index, waits for PK. Process B holds lock on PK, waits for NC index.
• Severity: Medium
• Cause: A query does a Key Lookup (NC index → PK), taking locks on both. Another query updates via the PK, taking locks in reverse order.
• Fix: Eliminate the Key Lookup by adding INCLUDE columns to the NC index so no bookmark lookup is needed. This removes the two-resource lock acquisition.

P6 — SERIALIZABLE Phantom Deadlock

• Signature: isolationlevel = serializable on one or more processes AND range locks (RangeX-X, RangeS-U) visible in the resource type.
• Severity: Medium
• Cause: SERIALIZABLE isolation holds range locks to prevent phantoms. Two transactions holding range locks on adjacent ranges block each other's inserts.
• Fix: Downgrade to SNAPSHOT isolation if application semantics allow. SNAPSHOT uses optimistic row versioning and eliminates range locks entirely. If SERIALIZABLE is required, reduce transaction scope.

P7 — Foreign Key Check Deadlock

• Trigger: objectname in the resource list references a parent table, and one process is inserting into the child table while another deletes from the parent.
• Severity: Medium
• Cause: Inserting into a child table takes a shared lock on the parent (FK validation). Deleting from the parent takes an exclusive lock. If done concurrently in opposite order, deadlock occurs.
• Fix: Add an index on the FK column in the child table (prevents table scan during FK validation). Ensure parent deletes and child inserts do not overlap in concurrent transactions.

P8 — Self-Deadlock (Single SPID)

• Signature: The deadlock graph shows the same SPID in multiple processes (different ECIDs, indicating a parallel plan) or a single process deadlocked with itself.
• Severity: Medium
• Cause: A single SPID is requesting a lock it already holds in an incompatible mode, or multiple execution contexts of the same SPID (parallel plan) block each other (rare; usually triggered by cursors, certain MERGE statements, or parallel query plans).
• Fix: Rewrite the query to avoid cursor-based row-by-row processing. Review MERGE statements for self-deadlock edge cases documented in KB articles. For parallel plans, consider reducing MAXDOP or simplifying the query.

P9 — RCSI Reader Deadlock Despite RCSI Enabled

• Signature: READ_COMMITTED_SNAPSHOT is ON for the database yet the deadlock involves a reader (S lock) and a writer (X lock) in a cycle.
• Severity: High
• Cause: One or more sessions is using an isolation level that still takes shared locks despite RCSI — REPEATABLE READ, SERIALIZABLE, or an explicit WITH (HOLDLOCK) / WITH (UPDLOCK) hint overrides RCSI for that statement. RCSI only removes S locks for READ COMMITTED; higher isolation levels retain them.
• Fix: Identify the isolation level of the reader process (isolationlevel attribute). If REPEATABLE READ or SERIALIZABLE is not required by the application, downgrade to READ COMMITTED. Remove unnecessary WITH (HOLDLOCK) hints.

P10 — MERGE Statement Deadlock

• Signature: One or more processes has a MERGE statement in its `` as the active frame.
• Severity: High
• Cause: MERGE uses Halloween Protection — it must read all matching rows before writing any, which creates an internal spool. This spool acquires a mix of S and X locks in a pattern that can cycle with concurrent MERGE or DML on the same table.
• Fix: Replace MERGE with explicit INSERT/UPDATE/DELETE statements. If MERGE is required, add WITH (TABLOCK) on the target as a short-term workaround (serializes all MERGE operations). Longer term, partition the target table or pre-stage source data to reduce concurrent overlap.

P11 — Heap Table RID Lock Deadlock

• Signature: Resource list contains ridlock entries instead of keylock entries.
• Severity: High
• Cause: The table has no clustered index (heap). SQL Server uses Row ID (RID) locks to lock individual heap rows. Because heap rows have no ordering key, concurrent operations may acquire RID locks in an unpredictable order, increasing deadlock risk. Additionally, if the optimizer chooses a page lock on a heap, the coarser page-level lock can conflict with other sessions.
• Fix: Add a clustered index to convert the heap to a B-tree table. Predictable key-level locks replace RID locks, reducing deadlock surface. Use /sqlindex-advisor to identify the best clustering key.

P12 — Distributed Transaction Deadlock

• Signature: One or more processes has transactionname containing "Distributed Transaction".
• Severity: High
• Cause: MS DTC coordinates a distributed transaction spanning multiple SQL Server instances or resource managers. Distributed transactions hold locks for the full duration of the two-phase commit protocol, which is significantly longer than local transactions. The extended lock hold time dramatically increases deadlock probability.
• Fix: Eliminate distributed transactions where possible by co-locating data on a single instance. If DTC is required, minimize transaction scope — commit or roll back as quickly as possible. Ensure DTC timeout settings are not artificially extended.

P13 — Multiple Deadlock Graphs: Shared Root Cause

• Signature: Multiple deadlock XML graphs are provided and all share the same objectname or indexname in their resource lists.
• Severity: High
• Cause: A single table or index is the hotspot for all deadlocks. This is not a set of independent incidents — it is one recurring access pattern that fires repeatedly under concurrency.
• Fix: Focus exclusively on the shared table. Apply the fix pattern appropriate for the individual deadlock type (P1–P12) detected in each graph. A single index addition or isolation level change to the shared table will resolve all graphs simultaneously.

P14 — TempDB Resource Deadlock

• Signature: objectname in the resource list is a tempdb object (tempdb.dbo.#temp or a system page like GAM, PFS, SGAM).
• Severity: High
• Cause: Concurrent DDL on temp tables (CREATE/DROP) under high parallelism contends on TempDB allocation pages. Multiple sessions creating and dropping temp objects simultaneously fight over PFS and GAM pages. User temp table DML can also deadlock when two sessions update the same temp table rows.
• Fix: For allocation page contention, increase TempDB file count to match CPU count (up to 8 files). On SQL Server 2014 and earlier, enable trace flag 1118 as a startup parameter; on SQL Server 2016 and later, uniform extent allocation is the default for TempDB and trace flag 1118 is not required. For user temp table deadlocks, apply the same lock-order fixes as P1.

P15 — Lock Escalation Deadlock

• Signature: Resource list contains an objectlock (table-level lock) alongside keylock or ridlock entries on the same table, held by different sessions.
• Severity: High
• Cause: SQL Server escalated row or page locks to a table lock for one session. Escalation is triggered when a single Transact-SQL statement acquires at least 5,000 locks on a single nonpartitioned table or index, or when lock memory exceeds the instance threshold. The escalated table lock conflicts with row-level locks held by another concurrent session.
• Fix: Prevent escalation with ALTER TABLE ... SET (LOCK_ESCALATION = DISABLE) if read isolation allows (note: disabling escalation can cause out-of-locks errors under heavy load). Alternatively, reduce transaction size so the 5,000-lock threshold is never reached. Enable RCSI to eliminate S locks from readers, reducing total lock count.

P16 — Ledger or Temporal History Table Deadlock

• Signature: objectname in the resource list references a ledger history table (named MSSQL_LedgerHistoryFor_...) or a temporal history table. Applies to SQL 2016+ (temporal) and SQL 2022+ (ledger).
• Severity: Medium
• Cause: Ledger and temporal tables maintain hidden history rows on UPDATE/DELETE. The system inserts history rows into a separate table, acquiring locks in an order that can conflict with explicit DML on the base table from another session.
• Fix: Ensure application code does not hold locks on the base table for extended periods (keep transactions short). If possible, route read queries against the history table to a secondary replica to reduce read/write contention on the primary.

P17 — Optimized Locking / TID Lock Deadlock

• Signature: SQL Server 2022+ with optimized locking enabled. The resource list contains ` elements (transaction ID locks) alongside the underlying keylock or ridlock. Each session holds an exclusive (X) lock on its own TID resource and waits for a shared (S`) lock on the other session's TID.
• Severity: High
• Cause: With optimized locking, writers acquire short-duration exclusive locks on row/page TIDs instead of holding locks until transaction end. Under concurrent updates on the same rows, two sessions can each hold an X lock on their own TID and wait for an S lock on the other's TID, forming a cycle.
• Fix: The deadlock is inherent to the optimized locking concurrency model at high conflict rates. Reduce transaction scope, retry deadlocked transactions in the application, and ensure rows are updated in a consistent order (as in P1). Optimized locking generally reduces deadlocks, but TID deadlocks can still occur under the same forward/reverse access patterns.

---

Lock Compatibility Reference

| Held \ Requested | S | U | X | IS | IX | SIX | |---|---|---|---|---|---|---| | S | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | | U | ✓ | ✗ | ✗ | ✓ | ✗ | ✗ | | X | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | | IS | ✓ | ✓ | ✗ | ✓ | ✓ | ✓ | | IX | ✗ | ✗ | ✗ | ✓ | ✓ | ✗ | | SIX | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ |

---

Version-Aware Check Suppression

If the SQL Server version is known — from the ServerVersion attribute in the plan XML or stated by the user — read VERSION_COMPATIBILITY.md (~/.claude/skills/VERSION_COMPATIBILITY.md if installed, or skills/VERSION_COMPATIBILITY.md from the repo). If unavailable, skip silently. For checks whose minimum version exceeds the instance version: verbose mode → log as SKIP (version: requires SQL 20XX+, instance is SQL 20YY); standard report → omit entirely. Do not suppress NOT ASSESSED rows from missing input — only suppress version-inapplicable checks.

---

Output Format

## Deadlock Analysis

### Deadlock Summary

| | Victim | Winner |
|--|--------|--------|
| **SPID** | X | Y |
| **Host** | [hostname] | [hostname] |
| **Procedure / Batch** | [proc name or first 80 chars of ad-hoc SQL, for display only] | [proc name or first 80 chars, for display only] |
| **Started** | [timestamp] | [timestamp] |
| **Log used** | [KB] | [KB] |
| **Pattern detected** | [P1–P17 or Unknown] | — |

### Lock Cycle

SPID X → holds [mode on object.index] → waits for [mode on object.index] SPID Y → holds [mode on object.index] → waits for [mode on object.index]

[One sentence confirming the circular wait and which SPID SQL Server chose as victim.]

### Pattern Match

**[Pattern name — e.g., P1 Classic Forward/Reverse Access Order]**

| Session | Step 1 | Step 2 |
|---------|--------|--------|
| SPID X — ProcA | [lock mode] on [Table1] ([index]) | Needs [lock mode] on [Table2] |
| SPID Y — ProcB | [lock mode] on [Table2] | Needs [lock mode] on [Table1] |

[One sentence explaining why this access order is deterministic and under what concurrency condition it fires.]

### Queries Involved

**Victim (SPID X) — [proc/batch name]**
```sql
[query text]

[One sentence: what lock it acquires and on which resource.]

Winner (SPID Y) — [proc/batch name]

[query text]

[One sentence: what lock it acquires first and what it then waits for.]

Root Cause

[Pattern name, why the cycle is deterministic, which tables/indexes are involved, and what concurrent execution condition triggers it.]

Remediation Plan

Fix 1 (Recommended) — [Action]

• Effort: Low / Medium / High
• Effectiveness: Eliminates / Reduces frequency / Hides symptom
• SQL: [DDL or setting change with

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: vanterx
• Source: vanterx/mssql-performance-skills
• License: MIT

Install and usage instructions live in the source repository linked above.