诊断事件跟踪 oracle,等待事件：Oracle 数据库的 reliable message 的含义和诊断分析...

在 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 .