今天客户的一套RAC环境出现问题
双节点RAC环境中,一个节点因为锁竞争而挂起,shutdown之后无法启动。
故障出现时我正在路上,匆匆回到家中,处理故障。
解决之后查找故障原因。
检查当时的AWR信息发现Top 5 Timed Events显示如下信息:
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
reliable message 354 89 251 219.4 Other
CPU time 32 78.3
db file sequential read 2,223 12 6 30.3 User I/O
control file sequential read 29,151 8 0 20.9 System I/O
db file scattered read 36 2 62 5.5 User I/O
-------------------------------------------------------------
这里最显著的事件是reliable message,这个事件Metalink的解释为:
When you send a message using the 'KSR' intra-instance broadcast
service, the message publisher waits on this wait-event until
all subscribers have consumed the 'reliable message' just sent.
The publisher waits on this wait-event for three seconds and
then re-tests if all subscribers have consumed the message, or
until posted.
也就是说当跨实例发送消息时,发送者期望收到订阅者的回复信息,如果得不到可信回复,就会一直处于等待。等待以3秒为周期进行反复尝试,知道收到所有订阅者的回复或者被唤醒。
那么在这个环境中,也就是说两个节点的通讯已经出现问题,一个节点得不到另外一个节点的回复。
这是一个可怕的故障,reliable message也是一个让人头疼的事件。
from:http://www.eygle.com/archives/2008/02/reliable_message.html
///
关于reliable message 等待事件的问题~
关于reliable message 等待事件的问题~
没怎么接触过RAC的系统~ 最近看一个两节点RAC的AWR的信息 发现Top 5 Timed Events
CPU time 413 96.2
reliable message 422 40 95 9.4 Other
log file sync 38,063 32 1 7.4 Commit
log file parallel write 36,133 20 1 4.7 System I/O
Streams AQ: qmn coordinator waiting for slave to start 2 11 5,369 2.5 Other
第二位是reliable message~ 不明白这个等待事件对性能有没有影响~
网上搜了一下 只搜到eygle大师关于这个等待事件的一点解释 ~
http://www.eygle.com/archives/2008/02/reliable_message.html
这里最显著的事件是reliable message,这个事件Metalink的解释为:
When you send a message using the 'KSR' intra-instance broadcast
service, the message publisher waits on this wait-event until
all subscribers have consumed the 'reliable message' just sent.
The publisher waits on this wait-event for three seconds and
then re-tests if all subscribers have consumed the message, or
until posted.
也就是说当跨实例发送消息时,发送者期望收到订阅者的回复信息,如果得不到可信回复,就会一直处于等待。等待以3秒为周期进行反复尝试,知道收到所有订阅者的回复或者被唤醒。
from itpub.net