oracle wait event:reliable message

tmxekoztne

　　今天客户的一套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