row cache mutex 事件诊断-凯发app官方网站

aix 19.11 单机，cpu特别高，跑批慢了，看看awr

主要等待事件是row cache mutex，查了查，在 12.2.0.1.0 (12cr2), "row cache mutex" 替代了 12.1.0.2.0 (12cr1) "latch: row cache objects"。

看到dc_rollback_segments请求次数非常多，这些cache的解释可以看 doc id 2016422.1

函数解释

看看ash

p1的值是3，对应的对象是：

引起这个事件的是一个简单的insert，没有高版本或大量硬解析

相关参数

也都做了预防。

下次发生再查：

select segment_name,status,tablespace_name from dba_rollback_segs where status = 'offline';
select latch#, child#, sleeps from v$latch_children where name='row cache objects' and sleeps > 0 order by sleeps desc;
select parameter, gets from v$rowcache order by gets desc;
select count(*),status from dba_rollback_segs group by status ;

--系统转储
sqlplus "/ as sysdba"
oradebug setmypid
oradebug unlimit
oradebug dump systemstate 266
wait 90 seconds
oradebug dump systemstate 266
wait 90 seconds
oradebug dump systemstate 266
quit
--当已经找到阻塞进程和被阻塞进程，可以使用 errorstack 取得相关进程信息，从而得到类似 systemstate dump 信息，来定位已知的问题。
$ sqlplus
sql> oradebug setospid <p.spid from above>
oradebug dump errorstack 3
<< wait 1min>>
oradebug dump errorstack 3
<< wait 1min>>
oradebug dump errorstack 3
exit
--有时 systemstate dump 是不适合收集的，因为它消耗资源较多。这时定期执行如下 sql，来确定哪些进程和 sql 在等待 library cache: mutex x。
select s.sid, t.sql_text
from v$session s, v$sql t
where s.event like '%mutex%'
and t.sql_id = s.sql_id

参考：
high requests on dc_rollback_segments (doc id 1951703.1)

阅读(2625) | 评论(0) | 转发(0) |

上一篇：无感知重置密码解决用户 expired(grace) 状态

下一篇：12c打补丁越来越难了 crs 起不来 crs-6706

给主人留下些什么吧！~~

| | | | |

感谢所有关心和支持过chinaunix的朋友们