Oracle Scratchpad

September 12, 2014

Unusual Deadlock

Filed under: Oracle,Troubleshooting — Jonathan Lewis @ 1:08 pm BST Sep 12,2014

Prompted by a question on OTN I came up with a strategy for producing an ORA-00060 deadlock that DIDN’T produce a deadlock graph (because there isn’t one) and didn’t get reported in the alert log (at least, not when tested on It’s a situation that shouldn’t arise in a production system because it’s doing the sorts of things that you shouldn’t do in a production system: but possibly if you’re trying to do some maintenance or upgrades while keeping the system live it could happen. Here’s the starting code:

drop procedure p2;
drop procedure p1;

drop table t1 purge;
create table t1 (n1 number);

insert into t1 values(1);
insert into t1 values(3);

create or replace procedure p1
        update t1 set n1 = 2 where n1 = 1;
        update t1 set n1 = 4 where n1 = 3;

create or replace procedure p2

        procedure q
                pragma autonomous_transaction;
                execute immediate 'drop procedure p1';


        update t1 set n1 = 4 where n1 = 3;


Of course you’re asking for trouble if you start doing DDL as part of your production code; and you’re asking for trouble if you start playing around with autonomous transaction; and if you use one to do the other you’re almost guaranteed to hit a problem eventually. All it takes in this case is a simple sequence of actions followed by a short wait (ca. 10 seconds):

Session 1: execute p1
Session 2: wait a couple of seconds, then execute p2

I got the following result from session 2:


ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource
ORA-06512: at "TEST_USER.P2", line 8
ORA-06512: at "TEST_USER.P2", line 14
ORA-06512: at line 1

While this doesn’t show up in the alert log, I do get a trace file dumped for the session; in fact I got a trace file from both processes. The trace from the process that reported the deadlock started like this:


  Performing diagnostic dump and signaling ORA-00060

  Complete deadlock information is located in the trace file of process (pid: 8, osid: 17861, DIA0)
    trace file: /u01/app/oracle/diag/rdbms/test/test/trace/test_dia0_17861.trc


*** 2014-09-09 12:44:13.427

    dump requested by process (pid: 8, osid: 17861, DIA0)
    trace file: /u01/app/oracle/diag/rdbms/test/test/trace/test_dia0_17861.trc

The other process didn’t mention a deadlock, but started at the “HUNG PROCESS DIAGNOSTIC” line – the trace file had been triggered by the DIAG process. Of course, the DIAG process also dumped a trace file, summarising the situation; and this started with the following important note:

*** 2014-09-09 12:44:13.426

DEADLOCK DETECTED (id=0xf678cfe3)

Chain Signature: 'enq: TX - row lock contention'<='library cache pin' (cycle)
Chain Signature Hash: 0x39f9868d

The rest of the trace file told me what the other two processes had been doing when the ORA-00060 was initiated, but the point I want to pick up here is that we have a very brief summary in the “Chain Signature” that tells us we’ve had a collision between some DML (enq: TX) and some sort of cursor-like problem (library cache pin) and not a simple data cross-over.

If you’ve looked at the original OTN posting you’ll see that the Chain Signature in that case is “Chain Signature: ‘library cache lock'<=’library cache pin’ (cycle)”, which indicates a collision restricted entirely to the library cache (the lock suggests someone is using a package/cursor while the pin suggests that another session is trying to destroy/(re)compile it – and they’re each trying to do it to each other’s package ! (In the past when I’ve a deadlock of this type it’s been reported as ORA-04020 rather than ORA-00060.) I still have to work out exactly how the OP got into their deadlock (especially in view of their latest comment) -but since I don’t have the right version of Oracle to hand, and it might be a version-specific bug, I don’t think I’m going to try.



  1. Hi Jonathan,

    Your emails are always fascinating and intriguing. Well, I was struggling with one issue this morning and I was surprised to see this – I thought it 12c vs 11g diff. But its not –

    If you run following –

    create table dept (deptno integer, dname varchar2(40)); 
    CREATE INDEX dept_ix ON dept (deptno); 
    insert into dept(deptno,dname) values(10,'ABC'); 
    INSERT INTO dept(deptno,dname) VALUES(10,'ABC'); 
    INSERT INTO dept(deptno,dname) VALUES(11,NULL); 
    INSERT INTO dept(deptno,dname) VALUES(NULL,NULL); 

    Comment by ora777 — September 12, 2014 @ 5:59 pm BST Sep 12,2014 | Reply

    • Your comment seems to be incomplete, but I guess you’re wondering why Oracle can create the constraint when you have duplicates and nulls in the PK columns. But that’s the way with constraints, if you create them “disable” it’s implicitly “novalidate” which means you can create them with bad data in place.

      Your comment has nothing to do with the posting, though, so shouldn’t be here. In the absence of any specific relevance to a posting Oracle’s OTN database forum or the Oracle-L list server would be better targets for your question.

      Comment by Jonathan Lewis — September 14, 2014 @ 10:12 am BST Sep 14,2014 | Reply

RSS feed for comments on this post. TrackBack URI

Comments and related questions are welcome.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Powered by