背景:
在学习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博客 ” ,链接:http://blog.itpub.net/9240380/viewspace-1828288/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/9240380/viewspace-1828288/