the same deadlock tree appears if the reason is ITL contention on heap table:

Deadlock graph:
                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TX-000a000f-00001880        83     152     X             85     253           S
TX-00120017-000018cb        85     253     X             82     111           S
TX-00210009-00000cde        82     111     X             84     209           S
TX-001f001a-00000cde        84     209     X             83     152           S

session 152: DID 0001-0053-00005149     session 253: DID 0001-0055-000046C4
session 253: DID 0001-0055-000046C4     session 111: DID 0001-0052-0001929D
session 111: DID 0001-0052-0001929D     session 209: DID 0001-0054-000049EF
session 209: DID 0001-0054-000049EF     session 152: DID 0001-0053-00005149

Rows waited on:
  Session 152: no row
  Session 253: no row
  Session 111: no row
  Session 209: no row


 Session Wait History:
        elapsed time of 0.000029 sec since current wait
     0: waited for 'enq: TX - allocate ITL entry'
...

Best regards,
Martin

Good strategic choice – there are plenty of things which are interesting oddities, but once we have a good enough idea of what’s happening it’s often time to take a quick note and move on. I often find that after collecting “partial solutions” over a period of time the moment comes when three of four pieces of information happen to fit together and give me some insight into a bigger design issue.

In passing I ran the test one more time with wait state tracing enabled (and a change of distributed lock timeout) and every single PX slave dumped the following trace (with different process and session ids for the waiter, of course) after waiting 20 times on a 3-second TM/3 enqueue:

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-000131f8-00000000        12      50     X             18      30          SX
session 50: DID 0001-000C-0000001B	session 30: DID 0001-000C-0000001B
Rows waited on:
Session 30: no row
Information on the OTHER waiting sessions:
End of information on OTHER waiting sessions.
Current SQL statement for this session:
INSERT INTO TESTSZ X
WITH X1 AS (SELECT /*+ PARALLEL(T,4) materialize */ 2000, K FROM TESTSZ T
WHERE I=1)
SELECT * FROM X1

But now, out of curiosity I changed on my test system the setting of distributed_lock_timeout parameter and retested after instance bounce.

On 10.2.0.4, parameter change had no effect:

SQL> select version from v$instance;

VERSION
----------
10.2.0.4.0

SQL> select name, value from v$parameter where name='distributed_lock_timeout';

NAME                      VALUE
------------------------- -----
distributed_lock_timeout  180


SQL> LOCK TABLE TESTSZ IN EXCLUSIVE MODE;

Tabelle(n) wurde(n) gesperrt.

SQL> set timing on
SQL> INSERT INTO TESTSZ X
  2   WITH X1 AS
  3    (SELECT /*+ PARALLEL(T,4) MATERIALIZE*/ 2000, K FROM TESTSZ T WHERE I=1)
  4   SELECT * FROM X1;
INSERT INTO TESTSZ X
*
FEHLER in Zeile 1:
ORA-12801: error signaled in parallel query server P000
ORA-00060: deadlock detected while waiting for resource

Abgelaufen: 00:01:04.66

So there must be some more to this, than I currently undertstand. Bu whatever it is, I don’t think it is that terribly important, so I leave it as it is.

Thanks for that, and sorry about the delay in follow.

The deadlock message looks as if it’s not the right one – the wait when I copied your test case was about 60 seconds (a little longer) which suggests it’s actually an “assumed distributed deadlock” (which is consistent with the whole parallel DML operation). Commenting out your “lock table in exclusive mode” obviously avoided the deadlock.

As far as I know, once you’ve covered the usual FK sinners, it’s only oddities of table locking for parallel, distributed, or autonomous transactions that can cause TM deadlocks.

Sligtly more on topic, did anyone know, that a single user connected session can cause a deadlock?

on 10.2.0.3 and 11.1.0.7 verified:

DROP TABLE TESTSZ;
CREATE TABLE TESTSZ
( I NUMBER,
  K VARCHAR2(50));
INSERT INTO TESTSZ
SELECT MOD(ROWNUM,1000), LPAD('X',40,'Y') FROM DUAL CONNECT BY ROWNUM < 1000000; 
COMMIT;
LOCK TABLE TESTSZ IN EXCLUSIVE MODE;
INSERT INTO TESTSZ X
WITH X1 AS (SELECT /*+ no_PARALLEL(T) MATERIALIZE*/ 2000, K FROM TESTSZ T
       WHERE I=1)
SELECT * FROM X1;
rollback;
LOCK TABLE TESTSZ IN EXCLUSIVE MODE;
set timing on
INSERT INTO TESTSZ X
WITH X1 AS (SELECT /*+ PARALLEL(T,4) MATERIALIZE*/ 2000, K FROM TESTSZ T
       WHERE I=1)
SELECT * FROM X1;
rollback; 

Result of the last insert statement:

INSERT INTO TESTSZ X
*
FEHLER in Zeile 1:
ORA-12801: error signaled in parallel query server P000
ORA-00060: deadlock detected while waiting for resource

Before anyone complains there are more than one session involved,
yes, but the importance is only one "user" connected session.

Moving back to TM locks, in the case above with the factored subquery
in combination with parallel query, the deadlock occurs while the sessions
are trying to get TM-locks.

SID	PROGRAM				LAST_CALL_ET	BLOCKING_SESSION	EVENT			SECONDS_IN_WAIT	
116	sqlplus.exe			48					PX Deq: Parse Reply	3	WAITING	
117	oracle@cyber-ora10 (P005)	48					PX Deq: Execution Msg	3	WAITING	
128	oracle@cyber-ora10 (P004)	48					PX Deq: Execution Msg	3	WAITING	
115	oracle@cyber-ora10 (P003)	48					PX Deq: Execution Msg	3	WAITING	
129	oracle@cyber-ora10 (P002)	48		116			enq: TM - contention	48	WAITING		
120	oracle@cyber-ora10 (P001)	48		116			enq: TM - contention	48	WAITING		
136	oracle@cyber-ora10 (P000)	48		116			enq: TM - contention	48	WAITING	
	

To finish, Oracle support aggreed, that this is not supposed to happen. The workaround is to use the inline hint.