问题描述
Mon Apr 15 06:54:15 2019
Global Enqueue Services Deadlock detected. More info in file
//oracle/diag/rdbms///trace/_lmd0_17544.trc.
Mon Apr 15 06:56:27 2019
Global Enqueue Services Deadlock detected. More info in file
//oracle/diag/rdbms///trace/_lmd0_17544.trc.
之前有看过一个类型的mos文档,说是bug,由于当前环境没那么快可以安排出停机计划,想知道是否是真的bug引起的,还是应用写的有问题。
专家解答
首先从trace中可以看出是LB类型的死锁,也就是Library Cache Lock
BLOCKED 0x13815c5290 5 wq 2 cvtops x1000 LB 0x58f64ef2.0x64524922(ext 0x0,0x0)[1019-0199-0000064E] inst 1 BLOCKER 0x1399cc1210 5 wq 1 cvtops x1010 LB 0x58f64ef2.0x64524922(ext 0x0,0x0)[2004-004E-00000B53] inst 2 BLOCKED 0x1399cc2800 5 wq 2 cvtops x1000 LB 0x635c12f2.0x486d1193(ext 0x0,0x0)[2004-004E-00000B53] inst 2 BLOCKER 0x13815c2a68 5 wq 1 cvtops x1010 LB 0x635c12f2.0x486d1193(ext 0x0,0x0)[1019-0199-0000064E] inst 1
resname : [0x635c12f2][0x486d1193],[LB][ext 0x0,0x0]
再查看大多数都是j00X进程在RECOMPILE_INVALID_PROCEDURE时候遇到(181个),
pid: 409 O/S info: user: oracle, term: UNKNOWN, ospid: 19256 image: oracle@epayrac01 (J000) client details: O/S info: user: oracle, term: UNKNOWN, ospid: 19256 machine: epayrac01 program: oracle@epayrac01 (J000) application name: DBMS_SCHEDULER, hash value=2478762354 action name: RECOMPILE_INVALID_PROCEDURE, hash value=842291206 current SQL: <none> DUMP LOCAL BLOCKER: initiate state dump for DEADLOCK possible owner[435.24415] on resource LB-635C12F2-486D1193
另外还有3个SQL:
current SQL: UPDATE TSTORE SET DEC_CHARGE_MONEY=:B3 ,DT_CHARGE_TIME=:B2 WHERE VC_STORE_ID=:B1 DUMP LOCAL BLOCKER: initiate state dump for DEADLOCK possible owner[62.17657] on resource LB-635C12F2-486D1193
current SQL: INSERT INTO "card_txn_daily_stat"@UMPS( "stat_date", "issue_no", "issue_sub_no", "user_no", "terminal_no", "stat_time", "center_charge_count", "center_charge_fee", "center_deal_count", "center_deal_fee") VALUES(:B10 ,:B9 ,:B8 ,:B7 ,:B6 ,:B5 ,:B4 ,:B3 ,:B2 ,:B1 ) DUMP LOCAL BLOCKER: initiate state dump for TIMEOUT possible owner[275.17783] on resource NB-63A16F37-0A606617
current SQL: alter procedure PSYS_DAILY_JOB_2 compile DUMP LOCAL BLOCKER: initiate state dump for TIMEOUT possible owner[177.17069] on resource LB-8AD68FFF-6C18D585
其中主要是两个LB-635C12F2-486D1193和LB-58F64EF2-64524922两个resource的锁。
1、请先检查trace中这些对象是否存在外部表,如果存在尝试禁用外部表的统计信息:
alter session set "_px_external_table_default_stats" = false;
2、检查job中调用的对象是否失效,如果失效手工编译是否可行
3、RAC中LB的死锁大多数还是bug,如果1和2无法解决问题,建议GRID和DB都安装最新的补丁
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。