0

等待事件:Oracle 数据库的 reliable message 的含义和诊断分析

eygle 2019-09-04
4900

在 Oracle 数据库中,有时候会看到一个奇怪的事件:reliable message ,当这个事件出现在 TOP 5 中时,可能就会引起大家的焦虑。

我整理一下关于这个事件的种种情形,供大家参考。


Reliable Message 它是一个通用等待事件,用于跟踪Oracle数据库中的许多不同类型的通道通信。很多人简单的将这个等待归入 Message 消息空闲等待,这是不对的,当这个等待出现时,一定意味着某些进程的通道通讯受到阻塞。当然影响主要是进程级别的,不是全局影响。但是一旦大量进程遭受影响,那么这个等待事件毫无疑问就会十分突出。


案例一:集群故障

双节点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秒为周期进行反复尝试,知道收到所有订阅者的回复或者被唤醒。

那么在这个环境中,也就是说两个节点的通讯已经出现问题,一个节点得不到另外一个节点的回复,如果只是普通的服务请求,影响的只是个别进程,通常不会引起全局问题

案例二:进程故障

以下是一位朋友提供的情形,例如当我们调用了 AQ ,但是没有设置 AQ进程,则数据库以此事件处于等待,设置 aq_tm_processes 参数 > 0 等待即可消除。

Althoug this is an old issue it just happened to in a test RAC. 

"reliable message" is really not to worry for but if some sessions are waiting and the wait time (secs) is increasing you may look at parameter aq_tm_processes: it should not be ZERO. 

If it is, set it to at least 2.


这种情况同样说的是进程等待,处于的空闲消息状态,因为工作任务得不到分配,当然需要关注和处理。


案例三:问题诊断


在遇到 reliable message 问题时,可以通过等待事件的参数进行进一步的诊断和分析。

在 v$event_name 视图中,我们可以找到该事件的三个参数的含义,三个参数分别代表 channel context ,channel handle ,broadcast message,获得这三个参数,就能够做出一定的判断:

SQL> select name,parameter1,parameter2,parameter3 from v$event_name where name='reliable message';


NAME

----------------------------------------------------------------

PARAMETER1

----------------------------------------------------------------

PARAMETER2

----------------------------------------------------------------

PARAMETER3

----------------------------------------------------------------

reliable message

channel context

channel handle

broadcast message


例如:在出现等待时,通过以下查询,获得 reliable message 的 P1 参数:

select to_char(p1, 'XXXXXXXXXXXXXXXX') event_param,
 count(*), sum(time_waited/1000000) time_waited
from gv$active_session_history
where event = 'reliable message'
group by to_char(p1, 'XXXXXXXXXXXXXXXX')
order by time_waited desc

EVENT_PARAM                                           COUNT(*) TIME_WAITED
--------------------------------------------------- ---------- -----------
       3CCF8A1D8                                          572  904.548231
       3CCF96200                                          109   69.145101
       3CCF9AFF0                                           54   23.987554

通过 x$ksrcdes 可以找到 P1 参数代表的通道信息:

select name_ksrcdes
from x$ksrcdes
where indx = (select name_ksrcctx from x$ksrcctx where addr like '%&addr%');
SQL> /
Enter value for addr: 3CCF8A1D8
NAME_KSRCDES
---------------------------------------------------------------------------
RBR channel


进一步的通过  GV$CHANNEL_WAITS 可以查看数据库的各种类等待。

有了这些信息,通过匹配 MOS 上的BUG内容,基本就可以确定是否是已知问题引起的,例如 RBR 相关的BUG就是:

Bug 15826962 High "reliable message" wait due to "RBR channel"

BUG描述:Increased in 'reliable message' waits may be seen associated to KSR Reuse
Block Range (RBR) messaging during Securefiles free space search.


可以看到这个BUG是因为 Securefiles 的自由空间扫描引发的,影响版本是 11.2.0.3 。


BUG 20470877 - LONG WAITS FOR "RELIABLE MESSAGE" AFTER A FEW DAYS OF UPTIME

BUG描述:CSS group membership query's are not processed fast enough because of congestion. 


这个BUG 是因为 CSS 的成员查询阻塞导致的,影响版本是 12.1.0.2 .


Wechat.jpg




最后修改时间:2019-09-04 09:15:23
「喜欢文章,快来给作者赞赏墨值吧」
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论

关注
最新发布
暂无内容,敬请期待...
数据库资讯
最新 热门 更多
本月热门
近期活动
全部
暂无活动,敬请期待...
相关课程
全部