数据库版本12.2.0.1
补丁集：12.2.0.1.210420
故障现象：与PTS用户所有相关的应用全部访问hang住。软件方的数据库监控报警：PGA使用率超过90%
临时解决方案：kill与PTS用户相关的所有session.
1.awr报告分析
db Time时间是平时的N倍
从mutex里面发现等待在getNextChild和addChindNode,初步判断是子游标出现了问题
据此判断大概率触发数据库BUG导致子游标没有被共享。通过查询mos，判断命中此BUG：
12.2 由于 Bind_equiv_failure 引发 SQL 不能共享进而造成 Cursor Mutex: x (Doc ID
2610645.1)
解决方案
打补丁 28794239
或者改变参数
alter system set "_optimizer_use_feedback"=false scope=spfile;
alter system set "_optimizer_adaptive_cursor_sharing"=false scope=spfile;
alter system set "_optimizer_extended_cursor_sharing_rel"=none scope=spfile;
alter system set "_optimizer_use_feedback"=false;
alter system set "_optimizer_adaptive_cursor_sharing"=false;
alter system set "_optimizer_extended_cursor_sharing_rel"=none;复制相关知识点
1.cursor: mutex X等待事件原理：
cursor 正在被解析并尝试以独占（exclusive）模式获取cursor mutex时产生的等待即为cursor:mutex X
引起问题的原因包括频繁硬解析、high version count、cursor失效及bug等。但本质上是一些会话长时间持有互斥锁，以至于其它会话不得不等待资源。如果在保护库缓存结构的latches/mutexes上发生争用，这意味着解析面临压力，解析sql需要更长的时间，因为它无法获得所需的资源，这会延迟其它操作，并且通常会降低系统速度。
触发原因：频繁硬解析、cursor失效、bug 、在一个父游标下面创建一个新的子游标、捕获SQL中的绑定变量、更新或构建SQL统计信息V$SQLSTAT
2.version count 原理：
一个SQL第一次执行时，会进行硬解析，同时创建parent cursor和child cursor。
当这个SQL时再次执行时，首先会对SQL语句进行特殊的hash运算，对应生成一个hash value。Hash value存放在parent cursor中，然后会用这个hash value到parent cursor的bucket中匹配，如果相同的hash value 已存在parent cursor里，则继续遍历这个child要cursor，如果可重用，那么就沿用child cursor的信息，如果不能重用，就会重新生成一个新的child cursor。一个parent cursor下child cursor的总数，就是这个SQL的version count。
high version count指的就是child cursor总数很高。在AWR报告中，默认version count超过20的SQL就会显示在order by version count中。根据经验version count如果超过100，可能就需要引起注意了。
评论
0
点赞