Skip to Main Content

Breadcrumb

Question and Answer

Chris Saxon

Thanks for the question, Rob.

Asked: October 21, 2016 - 2:34 pm UTC

Last updated: October 21, 2016 - 3:59 pm UTC

Version: 11.2.0.4.0

Viewed 10K+ times! This question is

You Asked

Hi Tom,

I'm not sure I understand the root cause of the following deadlock trace. Assuming I'm reading it correctly the trace is showing two different sql sessions attempting to delete the same row in the AAA_WF_OPERAND table. However, I do not see this behavior in our application log. Can you help me understand the root cause of this deadlock?

thanks,
Rob


DEADLOCK DETECTED ( ORA-00060 )

[Transaction Deadlock]

The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:

Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TM-00015d50-00000000 37 138 SX SSX 38 266 SX SSX
TM-00015d50-00000000 38 266 SX SSX 37 138 SX SSX

session 138: DID 0001-0025-00000004 session 266: DID 0001-0026-00000002
session 266: DID 0001-0026-00000002 session 138: DID 0001-0025-00000004

Rows waited on:
Session 138: no row
Session 266: no row

----- Information for the OTHER waiting sessions -----
Session 266:
sid: 266 ser: 19 audsid: 6991521 user: 115/AAA_SHAREDSVCS
flags: (0x45) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
flags2: (0x40009) -/-/INC
pid: 38 O/S info: user: risknavdba, term: SPPL01557, ospid: 6808
image: ORACLE.EXE (SHAD)
client details:
O/S info: user: SYSTEM, term: unknown, ospid: 1234
machine: SPPL01556 program: JDBC Thin Client
application name: JDBC Thin Client, hash value=2546894660
current SQL:
delete from AAA_WF_OPERAND
where WORKFLOW_OBJECT_ID = :1

----- End of information for the OTHER waiting sessions -----

Information for THIS session:

----- Current SQL Statement for this session (sql_id=2vmxn82bt84pf) -----
delete from AAA_WF_OPERAND
where WORKFLOW_OBJECT_ID = :1
===================================================

and Chris said...

By any chance do you have:

- Foreign keys pointing AAA_WF_OPERAND
- With the "on cascade delete" property
- And no indexes on the FK columns in these children?

If so, this could be the cause. The delete statement takes out a "Row-X (SX)" lock on the whole child table. This is to stop you inserting rows into the child for the parent you've just deleted.

If it is, the fix is easy:

Add an index to the FK columns in the child!

Rating

  (3 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Rob, October 21, 2016 - 3:34 pm UTC


Helpful so far!

Rob, October 21, 2016 - 3:36 pm UTC


Rob, October 21, 2016 - 3:56 pm UTC

Yes, we define three foreign keys that use cascading delete on two tables. Should an index be defined on all three of these columns?



Chris Saxon
October 21, 2016 - 3:59 pm UTC

Yes. You need indexes on all the columns pointing to the parent you're deleting from.