记一次Wait Classcursor: mutex X cursor: mutex S等待事件问题核查

客户环境是一套12.2.0.1的一体机rac，上午9点左右的是后客户说连不上库，是连pdb2的时候，客户端会卡在那边，没有返回；

我在服务器上直接sqlplus  abc/abc123456@mypdb2也连接不上，sqlplus一直无法返回，只能返回版本提示信息，无法进入sql>提示符

查看top，cpu负载很高；--5分钟10分钟，15分钟基本都在500+以上，vcpus 24

查看内存free -g ，剩余内存较多，还有50g+；swap未被使用过；

查看iostat感觉等待也还行，负载不是太高；

查看oracle进程连接，连接比较多ps -ef| grep LOCAL=NO，这套库配置的process比较高，10000这个没有超标；

昨天发生过一次，当时重启了pdb2就好了；但是过了一天，又发生了；

生成awr报告

db time时间很长，可见数据库目前负载很大；

 

并行latch里面的mutex X等待事件特别高，占所有等待事件的84.5；这个等待事件是保护库缓存内存结构的latch，跟sql解析hashvalue的内存结构有关；

查询了会话很多，而且active的会话都是waiting的状态，都在等待资源，由上面的等待事件来看，应该就是在等待mutex X的锁；

set linesize 1000 pagesize 1000
col instance_number for 999999
col session_id for 9999999
col session_serial# for 99999999
col SQL_ID for a20
col EVENT for  a15
col BLOCKING_INST_ID for 999
col BLOCKING_SESSION for a10
col BLOCKING_SESSION_SERIAL# for 9999
col PROGRAM for a20
select instance_number,session_id,session_serial#,SQL_ID,EVENT,BLOCKING_INST_ID,BLOCKING_SESSION, BLOCKING_SESSION_SERIAL# ,PROGRAM from DBA_HIST_ACTIVE_SESS_HISTORY where SAMPLE_TIME between to_timestamp('202303210900','yyyymmddhh24mi') and to_timestamp('202303211000','yyyymmddhh24mi') and rownum <10000;

 

 查询该时间段执行的sql，发现这条sql数据量特别多，而且都在不同会话等待相同的mutex s锁资源；

select sum(cnt) from (
select instance_number,session_id,session_serial#,count(1) cnt
from DBA_HIST_ACTIVE_SESS_HISTORY
 where SAMPLE_TIME between to_timestamp('202303210900','yyyymmddhh24mi') 
 and to_timestamp('202303211000','yyyymmddhh24mi') 
 and SQL_ID = 'f0h5rpzmhju11'
 and PROGRAM='JDBC Thin Client'
 group by instance_number,session_id,session_serial# ) 
;

 

 相同会话等待锁数量在200-300，不同会话总共并发等待锁在107万条；也就是说单会话互相等待资源数量在200-300个，总的会话互相等待锁的数量在107万个；这个压力非常大；

搜了mos，关于这个事件和versioncount的相关bug在12c中非常多，基本在最新的dbru中都包含了，所以打上最新的patch就可以；

从业务层面，可以将sql变换一下，/*sql1*/

/*sql2*/这样也可以；