Re: RAC internals - GLOBAL ENQUEUE SERVICES DEADLOCK DETECTED

Dusan Bolek wrote:
> We're encountering many of "Global Enqueue Services Deadlock detected"
> messages in the alert log of one of our database instances (two node
> RAC database) together with quite big global cache cr request waits in
> STATSPACK report. The problem is that the only other available
> information is trace file that looks like:
>
> *** 2005-09-19 10:37:01.153
> Global Wait-For-Graph(WFG) at ddTS[0.0] :
> BLOCKED 70000016f956fd8 5 [0x2b90011][0x5f20],[TX] [131321,1285] 1
> BLOCKER 70000016b5ff288 5 [0x2b90011][0x5f20],[TX] [131317,1159] 1
> BLOCKED 70000016b1c8440 5 [0x3fe001d][0x1a1d],[TX] [131317,1159] 1
> BLOCKER 700000199574ea0 5 [0x3fe001d][0x1a1d],[TX] [131321,1285] 1

Dusan,

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. Unlike in a single instance deadlock graph, a Global Wait-For-Graph is missing the current SQL. The good news to you is that your database is capable of producing this deadlock involving only one instance. So set cluster_database to false and try to reproduce the deadlock to get a better trace file.

Note:181489.1 has an interesting section about global cache cr request. But I think it's unrelated to the above deadlock.

>
> and sometimes also like:
>
> ----------enqueue------------------------
> lock version : 10665
> Owner node : 0
> grant_level : KJUSEREX
> req_level : KJUSEREX
> bast_level : KJUSERNL
> notify_func : 0
> resp : 7000001b13711d8
> procp : 700000160d71fa0
> pid : 5365832

That looks like lkdebug output and is about a different instance, a different process. But confirm with Oracle support.

Yong Huang Received on Wed Nov 02 2005 - 12:53:12 CST