An order application intermittently receives errors stating that its transaction was chosen as a deadlock victim and rolled back. The errors happen a few times a day under normal load, and retrying usually succeeds. What should the DBA do to address the cause?

A deadlock occurs when two or more transactions each hold locks the others need, forming a cycle that cannot resolve on its own. The engine detects the cycle and rolls back one transaction, the deadlock victim, so the others can proceed. Deadlock monitoring records which sessions, statements and resources were involved and the order in which locks were acquired. With that evidence the DBA can change the code so transactions access objects in a consistent order, shorten transactions, add indexes that reduce the rows locked, or adjust isolation levels. Raising the command timeout does not help, because a deadlock is resolved by detection, not by waiting; the victim is rolled back regardless of how long the client is willing to wait. Adding processor cores might shorten some transactions slightly, but a deadlock depends on lock ordering, and faster execution does not remove the cycle when the same conflicting access patterns occur. Turning off deadlock detection, where an engine allows it at all, would leave the cycle unresolved so the sessions would wait until a lock timeout, causing hangs rather than quick errors. Exam caveat: application retry logic for deadlock victims is good practice but treats the symptom; monitoring identifies the cause. Operational check: enable deadlock capture, collect several events, identify the recurring statements and objects, apply a consistent access order in non-production, and confirm the deadlock rate drops.