Oracle RAC ORA-29770异常重启：DRM与心跳网络故障排查

近期在云栈社区的技术公众号上，我们收到一则典型的 Oracle RAC 故障案例：一节点多次异常重启，报错 ORA-29770：global enqueue process LGWR is hung for more than n seconds。本文将对这一故障进行深度复盘，分析其根本原因及解决思路。

问题概述

集群一节点多次异常重启，报错 ORA-29770：global enqueue process LGWR is hung for more than n seconds，随后 LMHB 进程终止数据库实例，需要定位根本原因。

问题原因

ASH 等待分析

先分析 ASH 数据：

从 ASH 中看到异常等待非常多，根据报错信息，问题指向 LGWR 进程 hung，接下来分析 LGWR 的等待链：

LGWR 被会话 4983 阻塞：

4983 为 log writer 进程，等待 log file parallel write 和 wait for scn ack。但通过 OSW 排查，当时存储链路正常，写入没有瓶颈，因此主因应是节点间交互。

根据异常等待事件统计，gcs enter server mode 特别严重，这是一个全局资源协调等待事件，说明两节点资源协调出现异常。继续分析该等待事件：

阻塞源为会话 2069：

2069 正在执行 remaster 操作（DRM），其阻塞源为会话 7051：

7051 为 RSnn 进程，该进程主要负责处理远程实例请求（例如跨节点缓存数据访问）。从上图可见 RSnn 进程是最终阻塞者（final blocker），说明此时集群心跳已几乎不可用——可能是网络被打满，也可能是心跳链路本身故障。

网络层面

查看心跳网络监控：

根据客户提供的心跳网络监控数据，可以发现当时心跳流量巨大，且存在大量丢包。同时检查发现心跳网卡的 MTU 仅为 1500，大量增加了拆包/组包的负载。

再查心跳网卡配置：

另外根据 AWR 负载分析：

Redo 速率高达 9MB/s，集群等待较多的 SQL 几乎全为高并发的 DML，均表明当时节点间资源交换非常频繁。期间触发了 3 次 DRM 操作，同时伴随大量的 gc buffer、row cache lock 等一系列高并发和 cluster 相关等待。

分析结论

1. 跨节点并行大量的 DML，导致节点间缓存数据交换频繁。
2. DRM 未关闭，导致频繁 DRM，进一步加重了心跳流量与全局资源锁竞争。
3. _use_single_log_writer 未关闭，多个 log writer 在内部管理和切换上引发 lgwr worker group 相关等待。
4. 心跳网卡 MTU 偏小（1500），导致网络拆包/组包频繁。

解决方案

1. 结合实际业务进行拆分，单节点运行，减少实例间数据频繁交换。
2. 关闭 DRM （需要重启数据库）：

   alter system set "_gc_policy_time"=0 sid='*' scope=spfile;
   alter system set "_gc_undo_affinity"=FALSE sid='*' scope=spfile;

3. 调整 LGWR 相关隐含参数 （需要重启数据库）：

   alter system set "_use_single_log_writer"=FALSE sid='*' scope=spfile;
   alter system set "_use_adaptive_log_file_sync"=FALSE sid='*' scope=spfile;

4. 将心跳网卡 MTU 调整为 9000 （需要重启网卡及集群；如果经过交换机，交换机相应端口也需同步调整）。