SQL Server engine errors
Deadlock
Reviewed for reference consistency: August 11, 2026
the transaction was deadlocked on resources with another process
What 1205 Means
The 1205 error on the SQL Server engine errors indicates deadlock — the transaction was deadlocked on resources with another process. This typically occurs due to two processes holding locks that the other process requires.
Deadlocks occur when two or more tasks block each other indefinitely, each holding a lock the other needs to finish. SQL Server detects this and terminates one of the sessions as a victim. A lock monitor searches for waiting cycles every five seconds by default and breaks the circle by rolling back the transaction that is least expensive to undo. The 1205 message names the process chosen as the deadlock victim, and because that transaction was rolled back in full, resubmitting it is safe.
How to fix 1205
General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.
Retry the victim transaction
A deadlock victim is safe to retry. Catch error 1205 in the application and re-run the transaction a few times with a short backoff.
Capture the deadlock graph
Enable deadlock logging so SQL Server writes the cycle to the error log; review it, then turn the flag off afterward.
High-impact command - back up first and proceed carefully.
DBCC TRACEON (1222, -1);Read the deadlock graph from system_health
SQL Server keeps recent deadlock reports in the always-on system_health session's ring buffer, with no setup required. This listing is read-only and returns each captured report as XML.
SELECT xdr.query('.') AS deadlock_report FROM (SELECT CAST(target_data AS XML) AS td FROM sys.dm_xe_session_targets st JOIN sys.dm_xe_sessions s ON s.address = st.event_session_address WHERE s.name = 'system_health' AND st.target_name = 'ring_buffer') AS t CROSS APPLY t.td.nodes('RingBufferTarget/event[@name="xml_deadlock_report"]') AS x(xdr);Access tables in a consistent order
Deadlocks form when two transactions lock the same resources in opposite order. Touching tables in the same order everywhere breaks the cycle.
Shorten and index the transactions
Find scans that hold locks too long and add supporting indexes so locks are held briefly.
SET STATISTICS IO ON;
Technical Background
Deadlocks are a normal part of database operations in high-concurrency environments. They are not errors in the traditional sense but rather a 'stalemate' that SQL Server resolves by choosing one transaction to be the 'victim' and rolling it back.
SQL Server uses a background process called the Deadlock Monitor to detect these cycles. The monitor periodically checks for blocked tasks and, if it finds a circular dependency, it terminates the transaction that is least 'expensive' to roll back.
The victim is not chosen arbitrarily. With equal deadlock priority the engine picks the transaction that is cheapest to undo; an application can influence this by setting DEADLOCK_PRIORITY per session, which is how batch jobs are made to absorb deadlocks that would otherwise hit interactive requests.
Detection is continuous but lightweight. A lock monitor thread searches for cycles on a five-second default interval, and when deadlocks turn frequent the interval tightens to as little as 100 milliseconds, so a real cycle never survives long enough to stall the system on its own.
Common Causes
- Two processes holding locks that the other process requires
- Inefficient query patterns causing long-held locks
- Updating tables in a different order across different transactions
- Transactions left open across user interaction or external calls while their locks stay held
- Read locks held longer than needed under REPEATABLE READ or SERIALIZABLE
Typical Scenarios
- High-traffic systems updating the same rows from multiple threads
- Complex reports running simultaneously with data entry operations
- Two sessions updating the same pair of tables in opposite order, each waiting for the other's row locks
- A reader and a writer contending under a higher isolation level, each holding the lock the other needs next
What to Know
Designing application code to handle error 1205 through automated retries is a standard resilience pattern. Deadlock prevention involves consistent table access orders and minimizing transaction duration.
Frequently Asked Questions
Common questions about SQL Server 1205 error
No, deadlocks are almost always a result of application logic and query design patterns.
No. Blocking is one-sided: a transaction waits for a lock the holder releases when it finishes, so the wait ends when the owner completes. A deadlock closes the circle — each side holds what the other needs — and both would wait forever unless the engine breaks the cycle. The asymmetry is duration: the engine breaks a deadlock within moments, while ordinary blocking has no time limit of its own.
Whichever transaction is cheapest to undo. A session can raise its DEADLOCK_PRIORITY — LOW, NORMAL, HIGH, or any number between -10 and 10 — and when priorities differ, the lower one loses; when priority and cost tie, the engine picks randomly.
Yes — the victim's transaction was rolled back in full, so nothing partial remains. Rerun it after a short pause, and randomize that pause so retried transactions do not line up and deadlock again in the same pattern.
The system_health Extended Events session captures the xml_deadlock_report by default, and its ring buffer holds recent deadlock graphs with the victim, the processes, and the resources involved. Trace flags 1204 and 1222 write the same detail to the error log but are discouraged on busy systems because of their overhead.
Related Errors From Other Categories
Similar error codes documented across different platforms and systems
Process Killed — the process was terminated by a SIGKILL signal
Signal 11 (SIGSEGV) — kernel signal for invalid memory reference segmentation fault
Exit Code 139 — process terminated by segmentation fault (Signal 11 / SIGSEGV)
Input/output error EIO — a read or write operation could not complete