reliable message等待事件表明RAC节点间KSR广播通信阻塞，非空闲等待，而是发送方等待所有订阅者确认消费消息，默认3秒超时重试；大量出现即意味着私网延迟、HAIP异常或result cache相关bug等底层基础设施故障。
reliable message 等待事件说明：不是空闲等待，是通信阻塞信号
这个等待事件出现在 awr 的 top 10 中，就代表 rac 节点间消息广播卡住了——不是“等一会儿”，而是发送方在等所有接收方确认消费完消息，超时（默认 3 秒）后重试。它本身不报错，但大量出现一定意味着底层通信异常。
关键点在于：reliable message 是 KSR（Kernel Service Reliable）广播机制的等待，和 gc cr block busy 或 enq: TX 这类业务锁等待性质完全不同。它不反映 SQL 逻辑问题，只暴露集群基础设施层故障。
常见诱因包括：
- 私网延迟高（如核心交换机跳数多、MTU 不一致、网卡丢包）
- HAIP 启动失败或不稳定（12c 默认启用，但日志里不报 GIPCD 错误）
- result cache 在 11.2.0.4/12.1 中存在已知 bug（
bug_19557279），导致Result Cache: Channel高频等待 - OCR/voting disk 访问延迟间接影响 CSSD 心跳同步，连带干扰 KSR 消息投递
查 gv$channel_waits 定位具体通道类型
别只看等待时间总和，先确认是哪个通道在拖后腿。执行：
SELECT channel, SUM(wait_count) sum_wait_count FROM gv$channel_waits GROUP BY channel ORDER BY sum_wait_count DESC;
结果中排第一的 channel 名就是根因线索：
-
Result Cache: Channel→ 指向result_cache_max_size配置 + bug_19557279，优先考虑禁用缓存或打补丁 -
kxfp control signal channel→ 和 ASM 实例间通信有关，检查ora.asm状态及 ASM 磁盘组 mount 是否正常 -
RBR Channel（Real-time Block Recovery）→ 可能与 block recovery 压力大或 log transport 延迟相关 -
obj broadcast Channel→ 对象级广播（如序列号缓存同步），常伴随高并发 DDL
注意：gv$channel_waits 是动态视图，需在等待高发时段实时查，AWR 里查不到细节。
验证 HAIP 和私网连通性（12c RAC 必做）
Oracle 12c 默认用 HAIP 替代 GIPCD 管理私网，但 HAIP 失败不会触发明显 CRS 错误，容易被忽略。
先确认 HAIP 是否生效：
ifconfig -a | grep -A5 haip
再测节点间私网延迟和丢包（用 HAIP 地址，不是 eth1 IP）：
ping -c 10 <haip_of_other_node> mtr --report --interval=0.5 <haip_of_other_node></haip_of_other_node></haip_of_other_node>
如果平均延迟 >5ms 或丢包率 >1%，立刻检查：
- 两节点私网网卡 MTU 是否一致（建议统一设为 9000，避免分片）
- 交换机端口是否 up，STP 是否收敛，是否有环路
- 防火墙是否放行 UDP 12345（CSSD 心跳）和 TCP/UDP 任意端口（HAIP 内部通信）
- 是否启用了
disable_haip参数（不推荐，仅临时诊断用）
直连私网网卡（绕过交换机）是最有效的压测手段，但必须在维护窗口操作。
结合 oraagent_grid.log 看资源链是否卡在通信依赖上
当 reliable message 占比突增，常伴随 GI 启动卡顿或资源反复 restart。此时打开 $GRID_HOME/log/，搜索关键词：
-
CRS-2674: Start of 'ora.asm' on '→ 查' failed asmalert_看 diskgroup mount 日志.log -
ORA-12547: TNS:lost contact或ORA-12170: TNS:Connect timeout→ 指向ora.cluster_interconnect.haip或ora.gpnpd初始化失败 -
Failed to write to /u01/app/grid/.../gpnp/init/→ 文件权限错误，属主不是.pid grid，目录不可写
特别注意：12c 中 ora.crsd 依赖 ora.gpnpd 和 ora.cssd，而这两者又强依赖私网通信质量。一个节点的 HAIP 不稳，可能让整个集群资源链卡住，表现为大量 reliable message 等待。
最易被忽略的是：私网不通时，olsnodes -n 可能仍显示双节点在线，但 crsctl stat res -t 里 ora.cluster_interconnect.haip 状态为 OFFLINE 或 INTERMEDIATE——必须人工核对，不能只信 olsnodes 输出。
