背景：

在学习oracle 10.2.0.1 rac时，发现RAC出现明显的GC CR REQUEST事件，导致select查询hang住，分析处理如下：

分析处理：

含义：
本地节点需要一致性读的UNDO数据不在本地节点，需要到远端节点获取，等待返回的过程。

先用下述SQL，查查本地节点一致性数据块获取的平均时间
select b1.inst_id,
b2.value "GCS CR BLOCKS RECEIVED",--总的数据块个数
b1.value "GCS CR BLOCK RECEIVE TIME",--总的获取时间
((b1.value / b2.value) * 10) "AVG CR BLOCK RECEIVE TIME (ms)"
from gv$sysstat b,
gv$sysstat b2
where b1.name = 'global cache cr block receive time'
and b2.name = 'global cache cr blocks received'
and b1.inst_id = b2.inst_id;

如果超过15ms,原因有几方面：
1，SQL编写不佳，引发不必要的数据访问，优化SQL即可
2，如果SQL没有明显问题，可能是网络的原因，请在告警日志查看cluster interconnect,想办法去优化或诊断网络
说白了，就是减少RAC节点之间的网络延迟（私网）
3，LMS是负责RAC节点之间的锁请求，如果发现OS对于LMS的调度有延迟或者OS负载极高时，可以考虑增加lms进程个数（由_lm_lms控制），或者提升lms进程的优化级，以优先获取CPU时间片
4，当然你也可以重布应用，尽量减少数据的跨节点的访问
5，如果你发现另一等待事件gc null to x，平均响应时间少于15ms,这很可能是一个关于统计信息出错的BUG，具体请见243593.1以及 Note: 181489.1

思考：

1,rac一些指标之间是有非常密切的联系的
2,lmd及lms的性能可能由一些v$sysstat指标进行评估，进而进行针对性的诊断与分析
3,还要对rac的机制及进程进行测试，方会有进一点的理解和思路

ITPub博客

oracle 10.2.0.1 rac发现sql查询hang之gc cr request

背景：

分析处理：

思考：

最新文章