如何诊断latch: row cache objects

作者介绍:裴征峰,现就职于北京海天起点,专家组成员,南京办事处负责人,持有OCP 10g、OCP 11g、OCM 11g证书,主要从事客户的现场维护,重大问题的解决,数据库性能分析,服务质量保证等工作。拥有超过八年的Oracle服务经验,具备丰富的行业服务背景,对Oracle数据库有深刻的理解,在Oracle数据库RAC以及高可用解决方案方面具有深厚的实践经验,擅长数据库故障诊断,数据库性能调优。

业务碰到的问题

Itsm业务在上午8点50左右碰到严重的数据库性能,数据库基本处理hang住状态。业务表示没有做什么特殊的操作。业务那边的监控如下:




诊断过程

这是一套RHEL6.3_x86_64上的11.2.0.4 RAC,PSU为11.2.0.4.7。由于是事后分析,只能登录到数据库上检查一下这段时间的活跃会话历史:

最严重的是latch : row cache objects,需要检查哪个latch有问题

可以看到问题最严重的latch是33014019240转成16进制为:7AFC9F4A8。

在v$latch_children中检查发现的latch信息如下:


这个子latch是row cache object的8号子latch。具体这个row cache objects的子latch是保护什么对象呢?可以如下检查:

从这里可以看出这个row cache objects的子latch是保护dc_users。这里猜测可能跟业务配错用户口令有关,但业务表示,没有动过应用,而且从监控可以看到是突然出现的。

这里检查了下争用latch : row cache object比较严重的SQL_ID

采样比较多的SQL_ID,查看执行计划,均有HASH JOIN。



在MOS上搜索”row cache objects” “dc_users” “hash join”,发现以下两篇文档:

Bug 13902396 – Hash joins cause “row cache objects” latch gets and “shared pool” latch gets (disabled fix) (文档 ID 13902396.8)

Slow Performance with High Waits for ‘row cache lock’ With Possible Database Hang (文档 ID 2189126.1)

当然,由于是事后分析,没法看到当时进程的堆栈里是否有调用ktatminextsz,但是检查了latch : row cache objects争用比较大的SQL_ID,执行计划里都是有HASH JOIN。所以是比较符合Bug 13902396和2189126.1的描述。

解决办法

在11.2.0.4的版本上,打补丁13902396(这个补丁没包括在任何PSU内),然后设置如下Event:

event=’45053 trace name context forever, level 127′

未经允许不得转载:Oracle一体机用户组 » 如何诊断latch: row cache objects

相关推荐