Today,I found an error in alert.log of rac environment.the error like that:
Wed Dec 15 10:01:06 2010
Global Enqueue Services Deadlock detected. More info in filen /home/oracle/admin/abc/bdump/abc1_lmd0_5322.trc.
As we know,the “ges(lmd process)” control the lock in rac,and if GES deadlock detected,may be the application error happen.you should change the application script.
Followed,you see the trace file.
And the abc1_lmd0_5322.trc contains the follow contents:
*** 2010-01-08 12:00:32.800
*** SESSION ID:(4.1) 2010-01-08 12:00:32.799
open lock on RM 0 0
Dump file /home/oracle/admin/abc/bdump/abc1_lmd0_5322.trc
Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production
ORACLE_HOME = /home/oracle/product/920
System name: HP-UX
Node name: abc
Release: B.11.23
Version: U
Machine: ia64
Instance name: abc
Redo thread mounted by this instance: 0
Oracle process number: 5
Unix process pid: 5322, image: oracle@abc (LMD0)
*** 2010-08-27 01:55:10.788
*** SESSION ID:(4.1) 2010-08-27 01:55:10.629
open lock on RM 0 0
*** 2010-08-27 09:52:35.427
Global Wait-For-Graph(WFG) at ddTS[0.0] :
BLOCKED c0000002ee368b30 5 [0x290015][0xe186c],[TX] 131107 1
BLOCKER c0000002ed579568 5 [0x290015][0xe186c],[TX] 131114 1
BLOCKED c0000002ed5796d0 5 [0x11000e][0xfeff2e],[TX] 131114 1
BLOCKER c0000002ee368860 5 [0x11000e][0xfeff2e],[TX] 131107 1
………………………………………
*** 2010-12-15 10:01:06.101
Global Wait-For-Graph(WFG) at ddTS[0.1cc8] :
BLOCKED c0000002ee0a6400 5 [0xb001f][0x23a46d4],[TX] [131341,970741] 1
BLOCKER c0000002ef368860 5 [0xb001f][0x23a46d4],[TX] [131346,1602180] 1
BLOCKED c0000002ef368860 5 [0xb001f][0x23a46d4],[TX] [131346,1602180] 1
BLOCKER c0000002ef0a7d80 5 [0xb001f][0x23a46d4],[TX] [131340,1356768] 1
BLOCKED c0000002ef0a7ee8 5 [0x110012][0x106976e],[TX] [131340,1356768] 1
BLOCKER c0000002ee0a5e60 5 [0x110012][0x106976e],[TX] [131341,970741] 1
As you can see,the enqueue is “TX”,so ,maybe it’s applition error.
And see the red line,it shows that this trace file contain the history that the ges had met the deadlock,not just now.
How can you explain the “BLOCKED c0000002ee368b30 5 [0x290015][0xe186c],[TX] 131107 1”?
See this:
QUOTE:最初由 ddba 发布
谁帮忙解释一下如下信息的含义
alert日志出现了死锁信息,但是在数据库中查询不到相关的信息,请教各位 如下trace信息如何读取?
*** SESSION ID4.1) 2007-09-05 01:12:02.846
open lock on RM 0 0
*** 2007-09-05 02:09:12.866
user session for deadlock lock 7000002daeeef60
pid=163 serial=175 audsid=1417466022 user: 3402/ONEBOSS
O/S info: user: , term: , ospid: 1234, machine: IBOSS1_B1
program:
client info: 10.110.2.223
Current SQL Statement:
UPDATE TOBIMPSBIZPORTALMSG SET PRRESULT=:1,HOPRTIME=:2 WHERE PRNUMB=:3 AND IDVALUE=:4 and ACTIONCODE='0'
Global Wait-For-Graph(WFG) at ddTS[0.7] :
BLOCKED 7000002daeeef60 5 [0xc002d][0x679508],[TX] [65699,33] 0
BLOCKER 7000002e2611660 5 [0xc002d][0x679508],[TX] [131181,21] 1
BLOCKED 7000002e26117c8 5 [0x3000f][0x52324c],[TX] [131181,21] 1
BLOCKER 7000002daeeedf8 5 [0x3000f][0x52324c],[TX] [65699,33] 0
这是RAC环境下两个node上的应用产生的死锁:
node 0 事务号为65699的事务在等待一个Mode 5的锁[0xc002d][0x679508] ,锁类型为tx.而这个锁的持有者是node1上的事务号是131181的事务.
而node1上事务号为131181的事务正请求一个mode 5的锁[0x3000f][0x52324c],该锁的类型也是tx,而这个锁的持有者是node0 上的事务号为65699的事务.
由于着两个事务互相请求并互相持有对方的资源,导致了死锁.
应该到应用里看一下,基本上是应用设计出了问题,该提交的时候没有提交导致的.
More detail information see these website:
http://yong321.freeshell.org/computer/deadlocks.txt
http://www.itpub.net/viewthread.php?tid=848733
metalink: ID 262226.1
an import information is that:
Unfortunately this graph will not show you the SQL that caused the deadlock.
There has been no reliable mechanism in RAC to dump the SQL for all sessions involved in a deadlock if the deadlock spans across instances. The debugging mechanisms have continually improved through various releases to add additional trace data and diagnostic information - 9.2.0.6, 10.2.0.4 and 11.1.0.6. What RAC detects is dumped in the Wait-For-Graph in the LMD trace file.
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14730395/viewspace-681906/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/14730395/viewspace-681906/