Home/ Questions/Q 7367873
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T03:35:31+00:00

As I understand it, the typical case of a deadlock involving row-locking requires four

  • 0

As I understand it, the typical case of a deadlock involving row-locking requires four SQL statements. Two in one transaction to update row A and row B, and then a further two in a separate transaction to update the same rows, and require the same locks, but in the reverse order.

Transaction 1 gets the lock on row A before transaction 2 can request it, transaction 2 gets the lock on row B before transaction 1 can get it, and neither can get the remaining required locks. One or either transaction has to be rolled back, so the other can complete.

When I review an Oracle trace file after a deadlock, it only seems to highlight two queries. These seem to be the last one out of each transaction.

How can I identify the other statements involved in each transaction, or is this missing in an Oracle trace file?

I can include relevant bits of the specific trace file if required.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You’re correct, in a typical row-level deadlock, you’ll have session 1 execute sql_a that will lock row 1. Then session 2 will execute sql_b that will lock row 2. Then session 1 will execute sql_c to attempt to lock row 2, but session 2 has not committed, and so session 1 starts waiting. Finally, session 2 comes along, and it issues sql_d, attempting to lock row 1, but, since session 1 holds that lock, it starts waiting. Three seconds later, the deadlock is detected, and one of the sessions will catch ORA-00060 and the trace file is written.

    In this scenario, the trace file will contain sql_c and sql_d, but not sql_a or sql_b.

    The problem is that information just really isn’t available anywhere. Consider that you execute a DML, it starts a transaction if one doesn’t exist, generates a bunch of undo and redo, and the change is made. But, once that happens, the session is no longer associated with that SQL statement. There’s really no clean way to go back and find that information.

    sql_c and sql_d, on the other hand, are the statements that were associated with those sessions when the deadlock occurred, so, clearly, Oracle can identify them, and include that in the trace file.

    So, you’re correct, the information about sql_a and sql_b is not in the trace, and it’s really not readily available.

    Hope that helps.

    • 0