1

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

eygle 2019-09-04
6904

在 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,当遇到Bug 20470877 时,通常可以在AWR报告中观察到类似如下的后台等待(CSS group membership query):
image.png

案例四:结果集缓存

如前所诉,当出现显著的 reliable message 等待时,应当诊断是哪一类通讯通道遇到问题,这可以通过统计 V$CHANNEL_WAITS 视图来获得。

例如如下案例,通过分析统计,处于第一位的是:Result Cache: Channel 。

SQL> SELECT CHANNEL,
  2    SUM(wait_count) sum_wait_count
  3  FROM GV$CHANNEL_WAITS
  4  GROUP BY CHANNEL ORDER BY SUM(wait_count) DESC;
 
CHANNEL                                                            SUM_WAIT_COUNT
---------------------------------------------------------------- ----------------
Result Cache: Channel                                                   429264591
RBR channel                                                                323918
kxfp control signal channel                                                145021
MMON remote action broadcast channel                                         4146
obj broadcast channel                                                         295
LCK0 ksbxic channel                                                            27
parameters to cluster db instances - broadcast channel                          2

这个问题是结果集缓存的Bug导致的,Bug号为19557279,该问题在Oracle 12.2版本中修复。参考:

Very High Waits for ‘reliable message’ After Upgrade to 11.2.0.4 When Using Result Cache (Doc ID 1951729.1)

如果未使用结果集缓存特性,可以通过临时关闭来解决:

SQL> alter system set result_cache_max_size=0;
 
System altered.

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

评论