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

最新推荐文章于 2024-09-21 17:55:25 发布

kadwf123

最新推荐文章于 2024-09-21 17:55:25 发布

阅读量618

点赞数

文章标签： oracle 数据库 mutex X

本文链接：https://blog.csdn.net/kadwf123/article/details/129700195

版权

客户环境是一套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# ) 
;