Error 1205 means SQL Server selected a transaction as a deadlock victim. Read the captured deadlock graph before changing timeouts, indexes or retry settings. The graph describes a cycle of resource ownership and waiting; it gives you a much stronger starting point than the final statement reported by the application.1
The practical objective is to reduce the conflicting access pattern and handle any remaining victim errors safely. A successful retry does not demonstrate that the conflict is harmless, and changing which transaction loses does not remove the cycle.
This article uses SQL Server 2022 and the built-in system_health session. It is source-researched guidance. No deadlock was generated, event session changed or production query executed for it.
Deadlocking is different from waiting
In ordinary blocking, a transaction waits for a resource that another transaction can eventually release. In a deadlock, the participants form a cycle: each needs something another participant holds, so none can finish by simply waiting longer. SQL Server detects the cycle, ends the victim's batch, rolls back its transaction and returns 1205.1
A hypothetical order workflow illustrates the shape. One transaction modifies an order and then its stock record. Another modifies that stock record and then the order. Each may hold its first lock while waiting for the other. The application screen that displays the error identifies the victim, but both access paths belong in the investigation.
This example is explanatory, not a claim that all deadlocks involve two tables or reversed update order. Microsoft documents cycles involving other resources, including workers and memory. Parallel execution and specialised locking behaviour can require a more detailed analysis than a two-session drawing.1
Preserve the graph and its context
For the SQL Server scope here, system_health captures xml_deadlock_report events by default. Its event-file target can be inspected through SQL Server Management Studio. Use an existing authorised DBA connection and the Extended Events target viewer to locate reports around the application error time. Export only the relevant events into the incident record.1, 2
Keep the original XML as well as a graphical rendering. The picture is useful for orientation; the XML contains fields needed to compare processes, statements and resource ownership precisely. Record instance identity, database, engine build, application release and the event timestamp with its time-zone interpretation.
Absence of a retained graph does not disprove a deadlock. Event targets have finite retention, and the source describes different file-size and file-count limits for editions. Inspect the actual session and retained files rather than assuming a universal retention duration. Microsoft recommends not stopping, altering or deleting system_health; use a separately reviewed collection design if the existing evidence is insufficient.2
Event content can include SQL text, object names and application information. Keep raw captures out of tickets or chat rooms with broader access than the database incident team. A useful external support extract preserves the dependency structure while removing unnecessary customer values.
Read the three parts in order
Microsoft describes three principal graph sections: victim-list, process-list and resource-list.1 Work through them as a connected record.
First, identify the victim. Match its process identifier to the process list. Do not confuse the XML's internal process identifier with the session number. Record which application operation received the error and whether the application retried it.
Second, inspect every participant. Compare session identifiers, execution context, transaction information, isolation level, execution stack and input buffer where present. A transaction may have acquired a lock in an earlier statement, so the currently displayed statement is not automatically the whole cause.
Third, follow ownership and waiting. For each resource, find the owner list and waiter list, including requested lock modes. Trace a route from a process to the resource it needs, to its owner, and onward until the route returns to the starting participant. Record that cycle in plain language.
For an object or index resource, resolve identifiers against the correct database and schema. An index name can be more informative than a table-level description because different execution plans can reach data through different indexes. Preserve the object definitions and relevant plans from the incident's release context; a later schema may no longer explain the same identifier or access path.
Turn the graph into a testable explanation
Use a compact evidence table rather than an immediate list of configuration changes.
| Evidence | Question it should answer |
|---|---|
| Victim and application operation | Which business request failed, and what did the client do next? |
| All participants and transaction boundaries | Which operations overlapped, and how long did each retain resources? |
| Resource owners and waiters | What exact cycle prevented progress? |
| Relevant query plans and indexes | Why did each statement acquire the resources shown? |
| Recurrence by operation pair | Is this one repeatable conflict or several different graph shapes? |
Group incidents by the resource and operation pattern, not solely by error number. Two unrelated deadlocks both return 1205. Conversely, a changing victim can belong to the same recurring cycle.
A useful explanation might be: two business paths update the same entities in opposite orders, and the graph confirms both requested resources were already held by the other transaction. A weaker explanation is: the server was busy, so increase the timeout. Longer client patience does not remove a cyclic dependency already detected by the engine.
Choose a correction that addresses the cycle
Microsoft's prevention guidance includes consistent object access order, shorter transactions and avoiding user interaction inside a transaction. It also discusses isolation and row versioning.1 These are options to evaluate against the actual graph and application semantics, not a set of settings to apply together.
Where reversed access order is established, align the business paths so they acquire resources consistently. Review all participating paths, including scheduled work and error recovery. Fixing only the victim's statement can leave the opposing transaction order intact.
Where unnecessarily long transaction scope contributes, move unrelated work outside the transaction only after confirming the required atomic boundary. A payment workflow, for example, needs explicit reconciliation design; reducing lock duration must not silently weaken its consistency contract.
An index or query change can alter the resources visited. That may help, but it needs plan evidence and workload validation. Do not add an index merely because an index name appears in the graph. Similarly, row-versioning isolation changes require correctness, version-store capacity and workload review. They are not a blanket cure for writer conflicts or non-lock resource cycles.
Changing deadlock priority influences victim selection. It does not eliminate the dependency. Reserve such a decision for a documented business-priority policy, with the losing workflow's recovery behaviour understood.1
Make retries a controlled application behaviour
SQL Server rolls back the deadlock victim's transaction. An application may retry the transaction after handling the error, but the retry boundary must represent the complete intended unit of work.1 Retrying only the final statement can be wrong if earlier work belonged to the rolled-back transaction.
As an editorial recommendation, use bounded attempts, an explicit delay policy and telemetry that records the original error and attempt count. Do not turn indefinite retries into a substitute for correcting a recurring access pattern. Preserve a visible failure when the retry budget is exhausted.
Check external side effects separately. A message or remote API operation may not participate in the database transaction. The application needs an idempotency or reconciliation contract before replaying it. A generic client timeout is also not interchangeable with a confirmed 1205: the evidence about completion differs.
Verification and return plan
Before approving a change, define a disposable concurrency test with the two relevant operations and representative data distribution. Deliberately exercising concurrency belongs in an authorised test environment; this article does not supply production deadlock-generation commands.
Measure completion, retries, graph recurrence and business results across comparable workloads. Acceptance should show that the original cycle has been removed or materially reduced within an agreed limit, that remaining retries are bounded and that no duplicate external work appears. A quiet minute at lower traffic is not sufficient evidence.
Keep the previous query, application release or configuration through the normal change process. If reverting, assess transactions and external effects already completed; a code rollback does not undo them. Preserve before-and-after graphs so a new conflict is not mistaken for the old one.
Limits and learning notes
Azure SQL Database does not provide the same built-in system_health session as the SQL Server scope used here.2 CLR, parallel-resource and other unusual graph types may need specialist review. Source analysis establishes the documented mechanism, not that any proposed fix has passed a workload test.
- The victim is the transaction SQL Server ended, not necessarily the sole faulty participant.
- The owner/waiter cycle is the central evidence.
- Safe retries support a correct transaction design; they do not replace it.
Acceptance checklist
- [ ] The retained deadlock graph identifies both owners, waiters and the resource cycle.
- [ ] The proposed access-order or transaction change addresses that cycle.
- [ ] Approved concurrency tests cover bounded retries and duplicate-safe external effects.
- [ ] Comparable workload evidence records recurrence, completion and the return plan.
References
- Deadlocks Guide - SQL Server | Microsoft Learn. Accessed 2026-11-01.
- Use the system_health session - SQL Server | Microsoft Learn. Accessed 2026-11-01.