Global Enqueue Services Deadlock --WFG的诊断

Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4 今天客户数据库报了一个死锁错误，alert.log里信息比较简单 Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4 Global Enqueue Services Deadlock detected. More info in file

 /oracle/admin/orcc/bdump/orcc1_lmd0_487646.trc.

打开trace文件显示：

Global Wait-For-Graph(WFG) at ddTS[0.d3] :

BLOCKED 70000010fa9cda0 5 [0x15001a][0x8e8c6],[TX] [2001-001A-0005831D] 1

BLOCKER 70000010fa9cc50 5 [0x15001a][0x8e8c6],[TX] [200B-00BF-000474CE] 1

BLOCKED 70000010cbf3fa0 5 [0x20001d][0x2bcbf],[TX] [200B-00BF-000474CE] 1

BLOCKER 70000010ca7e590 5 [0x20001d][0x2bcbf],[TX] [2001-001A-0005831D] 1

      第一列为：阻塞/被阻塞

      第二列为：lock pointer

      第三列为：锁模式

      第四列为：事务信息 将前2部分，补足8位连起来就是xid

      最后一列为：节点信息，从0开始，1就是节点2

     

      由于oracle检测到死锁并已解锁，为了不影响系统，将当时的归档日志拷贝到一台空闲的测试机上进行分析

      DBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME=>'归档日志全路径',OPTIONS=>DBMS_LOGMNR.NEW);

      DBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME=>'归档日志全路径');

      DBMS_LOGMNR.START_LOGMNR();--由于没有数据字典，这里就不设置参数了

      这时就可以通过V$LOGMNR_CONTENTS进行分析了

      将xid为0020001d0002bcbf 和0015001a0008e8c6 的日志信息通过时间段限制全部查询出来，就可以分析导致死锁的原因了

      我这个客户就是，一直有俩个session一个在不断更新一个表，一个在删除和添加数据，而大家有都不提交，最终导致了死锁

       在一个业务繁忙的系统里，数据库的手工操作要慎之又慎，即使需要操作，也要尽快提交

       想起以前的客户很喜欢用for update，曾经非常让人头疼

 

     

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/3326/viewspace-576446/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/3326/viewspace-576446/