您的位置：首页 > 其它

Latch：row cache lock 之 dc_rollback_segments等待

2020-02-11 20:49 686 查看

一．情况概述

数据库告警，报会话高。此时通过TOAD已经无法登录数据库，在服务器上操作，想保留会话，但是发现当时查询GV$SESSION都不响应，由于是线上系统，决定重启机器。重启系统后，系统并没有立即恢复，查询GV$SESSION依然不响应，但是查询V$SESSION是可以，当时要求把后台数据库的监控暂时停掉，并且手工KILL了部分进程。数据库恢复正常

（1）会话监控：会话异常高

（2）主机负载：主机负载高

二．分析

尽管当时我们没有能保留现场会话，并且监控也没有采集数据，幸运的是Oracle的DBA_HIST_ACTIVE_SESSION视图中还是保留了一些信息。

（1）等待事件分析：我们使用以下语句来查看10秒的一个采样

SELECT event, COUNT (*)

FROM DBA_HIST_ACTIVE_SESS_HISTORY

WHERE

sample_time >= 当时时间

AND sample_time 当时时间+10分钟

--AND EVENT='row cache lock'

GROUP BY event

ORDER BY 2 DESC

结果如下：

这个信息是比较重要的，此时发现LATCH的row cache lock等待事件严重。这是一个和解析有关的等待事件，如果这个等待事件严重，就可以解释为什么当时我们登录数据库查看gv$session都等待，因为解析等待。

（2）继续查看等待的内容：我们使用以下语句查看等待的内容

SELECT event,p1text,p1, B.PARAMETER , count(*)

FROM DBA_HIST_ACTIVE_SESS_HISTORY a,V$ROWCACHE b

WHERE sample_time >=

TO_DATE ('2013-06-28 15:40:00', 'yyyy-mm-dd hh24:mi:ss')

AND sample_time <

TO_DATE ('2013-06-28 15:40:10', 'yyyy-mm-dd hh24:mi:ss')

AND EVENT='row cache lock'

and a.p1=B.CACHE#

group by event,p1text,p1, B.PARAMETER ;

发现等待的是回滚段和序列

（3）dc_sequences的等待

这类等待通常是由于大量使用序列，但是没有给序列缓存产生的，我们可以查看当时等待的SQL，调整相应序列的缓存值，缓解序列等待。

（4）回滚段的等待：

SELECT sql_id,count(*)

FROM DBA_HIST_ACTIVE_SESS_HISTORY

WHERE sample_time >=

TO_DATE ('2013-06-28 15:40:00', 'yyyy-mm-dd hh24:mi:ss')

AND sample_time <

TO_DATE ('2013-06-28 15:40:10', 'yyyy-mm-dd hh24:mi:ss')

AND EVENT='row cache lock'

and p1=3

group by sql_id

order by 2 desc ;

发现这些sql是不同的功能，都是数据操作，都在等待回滚段。

此时我们也可以看一下dc_rollback_segments 的请求

SELECT B.BEGIN_INTERVAL_TIME, B.END_INTERVAL_TIME, a.*

FROM DBA_HIST_ROWCACHE_SUMMARY a, DBA_HIST_SNAPSHOT b

WHERE a.parameter = 'dc_rollback_segments'

AND A.SNAP_ID = B.SNAP_ID

AND B.INSTANCE_NUMBER = 1

ORDER BY a.snap_id, a.instance_number;

结果如下：我们可以重启后，dc_rollback_segments 的请求明显下降，因为当时重启后，我们手工扩展了回滚段。

（5）row cache lock和dc_rollback_segments的关系

Row cache lock的等待项上如果显示的是dc_rollback_segments，通常是由于等待回滚段扩展，这提醒我们回滚段100%的监控项也是需要的。

DC_SEQUENCES

Check for appropriate caching of sequences for the application requirements.
DC_USERS(一般是创建用户，修改用户出现，重启下DB OK）

Deadlock and resulting "WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!" can occur if a session issues a GRANT to a user, and that user is in the process of logging on to the database.
DC_OBJECTS

Look for any object compilation activity which might require an exclusive lock and thus block online activity.
DC_SEGMENTS

This is likely to be down to segment allocation. Identify what the session holding the enqueue is doing and use errorstacks to diagnose.To check on V$ROWCACHE

SQL> select PARAMETER ,COUNT ,GETS ,GETMISSES ,MODIFICATIONS from v$rowcache where cache#=13;

（6）个人分析：

row cache lock是一个数据字典缓存，保护share pool中的数据字典。当我们提交一个语句分析的时候，必须先解析这个语句是否合法，访问的对象是否存在，这就需要使用数据字典的信息。我们猜想，当解析语句的时候，通常会对dba_objects上添加一个共享锁，也就是说会话需要dba_objects的信息，数据字典缓存中存放了所有表的定义、Storage信息、用户权限信息、约束定义、回滚段信息、表的统计信息等。而这些信息都是在解析过程中必须用到的。

如果回滚段使用满了，那么所有使用回滚段的有可能产生等待回滚段的等待，最终导致了row cache lock上dc_rollback_segments 类型的等待。而如果row cache lock等待，这是一个和解析有关的等待，所有需要执行sql解析的会话都有可能需要等待。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/617982/viewspace-1449248/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/617982/viewspace-1449248/

点赞
收藏
分享
文章举报

crhuang1986 发布了0 篇原创文章 · 获赞 0 · 访问量 137 私信关注

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航