暂无图片
分享
Gavin Chan
2019-04-15
alert日志时不时有Global Enqueue Services Deadlock提示

Mon Apr 15 06:54:15 2019

Global Enqueue Services Deadlock detected. More info in file

 /epayrac/oracle/diag/rdbms/epay/epay1/trace/epay1_lmd0_17544.trc.

Mon Apr 15 06:56:27 2019

Global Enqueue Services Deadlock detected. More info in file

 /epayrac/oracle/diag/rdbms/epay/epay1/trace/epay1_lmd0_17544.trc.

之前有看过一个类型的mos文档,说是bug,由于当前环境没那么快可以安排出停机计划,想知道是否是真的bug引起的,还是应用写的有问题。

收藏
分享
8条回答
默认
最新
Gavin Chan
上传附件:补丁情况.TXT
暂无图片 评论
暂无图片 有用 0
Gavin Chan
上传附件:epay1_lmd0_17544.trc
暂无图片 评论
暂无图片 有用 0
Gavin Chan
上传附件:epay1_lmd0_17544.trm
暂无图片 评论
暂无图片 有用 0
章芋文

首先从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都安装最新的补丁

暂无图片 评论
暂无图片 有用 0
Gavin Chan

好的,我这边看看,谢谢

暂无图片 评论
暂无图片 有用 0
Gavin Chan

这个问题跟上周提的节点重启的问题是否是类似的原因?

另外上周提的那个问题的现象,昨天又出现了.....就算要打补丁,要改造成ogg等也非立刻能做的事情,除此之外,是否有其他的临时解决办法

暂无图片 评论
暂无图片 有用 0
盖国强
  1. 可以考虑将不同应用分散到两个节点;

  2. 认真排查应用,从源头上解决;

  3. 呼叫我司服务电话。



暂无图片 评论
暂无图片 有用 0
章芋文
问题已关闭: 问题已经得到解决
暂无图片 评论
暂无图片 有用 0
回答交流
提交
问题信息
请登录之后查看
附件列表
请登录之后查看
邀请回答
暂无人订阅该标签,敬请期待~~
暂无图片墨值悬赏