Re: RAC internals - GLOBAL ENQUEUE SERVICES DEADLOCK DETECTED

Dusan Bolek wrote:
> > Metalink Note:262226.1 offers some interpretation. Your process 131321
> > on node 1 is waiting for a TX lock in mode 5 (the two hex numbers,
> > 0x2b90011 and 0x5f20, may be id1 and id2 in v$lock, respectively).
> > Process 131317 on the same node is holding it.
>
> The strange thing is that I can find none of the processes that are
> participating in a deadlock.
> When checked against V$PROCESS, even immediately after a new dead lock
> emerges in trace file,
> there is no row returned from that table.
>
> --
> Dusan Bolek

You're right. I did some testing and find that the two numbers, [131321,1285], in your case, do not in any way denote a process (Note:262226.1 says the first number is PID). Instead they correspond to transaction_id0 and transaction_id1 of v$ges_blocking_enqueue, respectively (or the same in v$dlm_locks). Documentation says they're lower and upper 4 bytes of the transaction identifier where the lock belongs to. I can't find more information about it. Perhaps for our purpose, we can conceptually think of the combination of the two numbers, i.e. a transaction identifier, as a process identifier.

By the way, I do see the SQL involved in the global deadlock (tested in 9.2.0.7.0 on Linux):
...
*** 2005-11-04 13:38:33.199
user session for deadlock lock 0x7553ab14 ...
  Current SQL Statement:
  update test set a = :"SYS_B_0" where a = :"SYS_B_1" Global Wait-For-Graph(WFG) at ddTS[0.28] : BLOCKED 0x7553ab14 5 [0xf001d][0x8353],[TX] [2162689,7995] 0 ...

In any case, follow Jonathan's practical advice.

Yong Huang Received on Fri Nov 04 2005 - 14:24:17 CST