关于等待事件cursor:mutex X的一次案例分析

本文分析了一起在Oracle数据库中遇到的cursor:mutex X等待事件问题,该问题导致系统负载异常。经过排查,发现与绑定变量无关,而是由于统计信息收集后游标失效引发的解析风暴。通过调整统计信息收集任务的no_invalidate参数为false,成功减少了cursor:mutex X的争用,目前问题已得到缓解。
摘要由CSDN通过智能技术生成

数据库环境:oracle12.1.0.2.170718,两节点RAC+单实例ADG

日常巡检时候发现,晚上11点系统跑批的时候,会出现系统负载过高情况,明显有异于平时。但并不是每天晚上跑批都会出现该问题,一开始怀疑是跑批内容存在差异导致,后跟开发人员再三确认,跑批程序一致,数据也不相上下。

正常时,跑批期间DB Time:


异常时,跑批期间DB Time:


看看等待事件情况:

正常时的等待事件情况:


异常时的等待事件情况:


这个问题观察了有半个月的时间,发现问题的出现不存在规律性,更像是偶然事件,但偶发性概率较高,平均三四天就可能出现一次,有时候会连续出现两三天。

根据等待事件来看,主要是cursor:mutex X和library cache:mutex X,其中cursor:mutex X尤为突出。

关于cursor:mutex X的介绍:

某个进程申请以EXCL mode持有mutex时进入该等待, 该Mutex要么正被其他进程以SHRD模式参考,这导致X mode的申请必须要等待直到Ref count=0,  或者该mutex正被另一个进程以X mode持有。

触发该事件的情况有:

a、在一个父游标下面创建一个新的子游标

b、捕获SQL中的绑定变量

c、更新或构建SQL统计信息V$SQLSTAT

-----------------------------------------------------------------------

看下出问题时的TOP SQL&

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值