👋 我是三笠，一名专注数据库运维与架构的 DBA，平时分享数据库实战经验与技术笔记，个人网站：ora100.com

前言

最近处理了一起 Oracle 11g RAC 故障。

生产数据库的一个节点突然发生实例重启，Alert Log 中出现了 ORA-29770，提示 LMS 进程长时间没有响应。

最开始怀疑是服务器资源或者 RAC 私网问题，但检查下来，CPU、内存、磁盘 I/O 和网络都没有发现明显异常。继续分析 LMON、LMS 的 Trace，并结合 Oracle Support 的意见，最终将排查重点放到了 RAC 的 DRM 资源重配置和内部消息处理机制上。

这篇文章记录一下整个排查和处理过程。

故障是怎么发生的？

数据库环境是一套 Oracle 11.2.0.4 双节点 RAC，运行在 RHEL 7.9 上。

本文环境信息：

故障发生时，节点 2 的 Alert Log 中出现了：

ORA-29770: global enqueue process LMS0
is hung for more than 70 seconds

随后，LMHB 检测到多个 LMS 进程长时间没有正常响应，触发实例终止。

从实际日志看，LMS0、LMS1、LMS2 均出现了持续约 95 秒无法正常推进的情况。

随后节点 2 实例被终止，并由集群自动重新启动。

⭐ 这里需要注意：ORA-29770 并不是普通 SQL 执行报错，而是 Oracle RAC 检测到关键后台进程长时间无响应后触发的保护机制。

LMS 是 RAC 中负责 Global Cache Service（GCS）相关消息处理的重要后台进程。如果 LMS 无法及时处理集群消息，就可能影响 Cache Fusion 和实例间资源协调。

因此，出现这类问题时，不能只看数据库 Alert Log，还需要结合 LMS、LMON、LMHB 等后台进程的 Trace 进行分析。

CPU、磁盘和 RAC 私网有没有问题？

看到 LMS Hang，首先需要排除操作系统资源和网络问题。

毕竟 RAC 的 Cache Fusion 依赖节点间通信。如果服务器 CPU 长时间繁忙、内存资源紧张、磁盘 I/O 延迟严重，或者 RAC 私网出现异常，都可能影响集群消息处理。

这两台主机部署了 OSWatcher，采集间隔为 30 秒。

我们提取了故障时间前后的监控数据，重点检查：

• CPU 使用率及运行队列
• 内存和交换分区使用情况
• 磁盘 I/O 延迟与繁忙程度
• RAC 私网网卡统计
• 网络丢包及协议异常
• 故障时间段内的系统进程状态

两个节点均保留了故障时间段的 OSWatcher 数据。

结合 Oracle Support 的分析，故障期间没有发现明显的 CPU、内存或磁盘 I/O 资源瓶颈，RAC 私网也没有发现明显的丢包及网络重组异常。

这意味着暂时没有证据表明本次 LMS Hang 是由操作系统资源耗尽或者私网故障直接引起的。

当然，这不代表操作系统和网络绝对不存在任何问题，只是从当前证据来看，继续把排查重点放在底层资源上，价值已经不大。

于是我们继续分析数据库内部的 Trace。

Trace 中发现了什么？

在节点 2 的 LMON Trace 中，故障前出现了 DRM（Dynamic Resource Mastering）相关操作。

大约在 09:21:19，Oracle 开始执行一次 DRM 资源重配置：

DRM(121)

在这之前，数据库还出现了对象资源亲和性调整的相关记录。

涉及的对象主要是业务表对应的物化视图日志。

从 Trace 中可以看到，DRM 的部分阶段已经推进，包括资源冻结、清理以及部分同步操作，但后续处理没有正常完成。

与此同时，节点 2 的多个 LMS 进程出现长时间无法正常推进的现象。

进程调用栈中反复出现：

kjbrfnd
kjbmmsg2res
kjbmprlst
kjmxmpm
kjmpbmsg
kjmsm
ksbrdp

其中还可以看到与 GCS 资源处理相关的记录：

kjbr.h LINE:1610 ID:kjbmprlst: shadow

这些信息说明，故障期间 LMS 正在处理 RAC 内部的资源及消息相关操作。

结合 DRM 的执行时间，能够建立一条比较清晰的时间线：

从时间关系来看，DRM 资源重配置与 LMS Hang 高度相关。

不过，仅凭这些日志还不能直接认定 DRM 本身存在 Bug，也不能证明某个具体内部参数已经耗尽。

这也是后续需要 Oracle Support 协助分析的原因。

Oracle 为什么怀疑是 Ticket 耗尽？

我们将 IPS、TFA SRDC、OSWatcher 以及相关后台进程 Trace 提交给 Oracle Support。

Oracle 工程师检查后，认为操作系统和 RAC 私网没有明显异常，故障更可能发生在 Oracle RAC 内部资源管理及消息处理过程中。

工程师重点怀疑的是内部消息 Ticket 数量不足。

这里涉及一个隐藏参数：

_lm_tickets

根据 Oracle Support 的解释，它可以理解为 RAC 内部 UDP 消息处理相关的限流计数器。

如果相关消息处理受到限制，就可能影响内部通信的推进。

但这里有一个关键问题：

当前 Oracle 11.2.0.4 的 Trace 没有记录故障时 Ticket 实际使用情况的能力。

因此，工程师虽然高度怀疑 Ticket 耗尽，却没有办法通过现有日志直接证明。

同时，Oracle 也没有找到与本次故障现象完全一致的已知 Bug。

所以本次故障的结论应当是：

故障发生在 DRM 资源重配置期间，多个 LMS 进程长时间无法正常推进。Oracle Support 怀疑内部消息 Ticket 限制是诱因，但目前缺少直接证据确认根因。

这个结论比简单地说“DRM Bug 导致 RAC 崩溃”更加准确。

三个隐藏参数为什么要一起调整？

Oracle Support 最终建议调整三个隐藏参数：

ALTER SYSTEM SET "_gc_policy_time"=0
SCOPE=SPFILE SID='*';

ALTER SYSTEM SET "_gc_undo_affinity"=FALSE
SCOPE=SPFILE SID='*';

ALTER SYSTEM SET "_lm_tickets"=5000
SCOPE=SPFILE SID='*';

在修改之前，我们先检查了两个实例的实际参数值。

SELECT p.ksppinm AS parameter_name,
       v.ksppstvl AS value
FROM x$ksppi p
JOIN x$ksppcv v
  ON p.indx = v.indx
WHERE p.ksppinm IN (
    '_gc_policy_time',
    '_gc_undo_affinity',
    '_lm_tickets'
)
ORDER BY p.ksppinm;

检查结果：

其中，前两个参数用于规避 DRM 动态资源重配置相关问题，第三个参数用于放宽内部消息 Ticket 限制。

Oracle 工程师建议将 _gc_policy_time=0 与 _gc_undo_affinity=FALSE 配套设置。

但关闭 DRM 是否会影响性能，还要看业务访问模式。

举个例子：

如果某张表长期由节点 1 访问，那么 DRM 可以根据资源亲和性统计，将相关资源 Master 调整到节点 1，这种情况下可能有利于减少跨节点资源协调开销。

但如果同一批业务数据经常在两个节点之间交替访问，资源 Master 就可能反复调整，带来额外开销。

因此，DRM 并不是一定有益，也不是一定有害。

关闭 DRM 并不等于关闭 Cache Fusion。 RAC 仍然需要通过 Cache Fusion 完成跨节点数据块访问和一致性维护。

另外，当前每个实例的 SGA 只有 32GB。

我们专门向 Oracle 确认过，_lm_tickets=5000 是否适用于这种规模的 RAC。

Oracle 工程师明确答复可以使用，并表示该参数调整没有明显的额外资源开销。

需要强调的是，这三个参数均属于隐藏参数，不建议在其他生产环境中直接照搬，应结合具体版本、故障现象和 Oracle Support 的建议实施。

参数改完，为什么滚动重启失败了？

确认调整方案后，我们在维护窗口内将三个参数写入共享 SPFILE。

三个 ALTER SYSTEM 均返回：

System altered.

由于参数使用的是 SCOPE=SPFILE，修改完成后不会立即改变当前实例的运行值。

原本计划采用 RAC Rolling Restart，先重启节点 2，再重启节点 1，尽量减少业务中断。

于是先停止节点 2：

srvctl stop instance -d orcl -i orcl2 -o immediate

停止成功。

接着启动：

srvctl start instance -d orcl -i orcl2

结果启动失败：

PRCR-1013 : Failed to start resource ora.orcl.db
PRCR-1064 : Failed to start resource ora.orcl.db

ORA-01105: mount is incompatible with mounts
by other instances

ORA-01606: parameter not identical to that
of another mounted instance

看到这个报错，基本可以判断两个实例之间存在参数兼容性问题。

节点 1 还没有重启，内存中仍然使用原来的参数值。

节点 2 则尝试使用 SPFILE 中的新参数启动。

在 MOUNT 阶段，Oracle 检测到实例间存在不兼容的配置，因此拒绝继续启动。

这里需要说明，当前日志没有进一步明确指出究竟是哪一个隐藏参数触发了兼容性检查，因此不能简单认定三个参数全部都不支持 Rolling Restart。

不过对于本次变更而言，继续尝试逐节点重启已经没有必要。

既然维护窗口允许，我们决定直接停止整个 RAC 数据库，再统一启动。

全库重启后，两个实例恢复正常

首先停止整个数据库：

srvctl stop database -d orcl

确认两个实例停止后，重新启动：

srvctl start database -d orcl

这次没有出现启动错误。

检查数据库状态：

srvctl status database -d orcl

返回：

Instance orcl1 is running on node node1
Instance orcl2 is running on node node2

随后通过 SQL 查询两个实例：

SELECT inst_id,
       instance_name,
       host_name,
       status,
       database_status
FROM gv$instance
ORDER BY inst_id;

结果：

INST_ID  INSTANCE_NAME  STATUS  DATABASE_STATUS
-------  -------------  ------  ---------------
1        orcl1          OPEN    ACTIVE
2        orcl2          OPEN    ACTIVE

两个实例均已恢复正常。

接着查询隐藏参数：

PARAMETER_NAME                 VALUE
------------------------------ -----
_gc_policy_time                0
_gc_undo_affinity              FALSE
_lm_tickets                    5000

本次提供的参数查询结果来自节点 2，说明节点 2 已经使用新配置启动。

由于两个实例已经完成全库重启，节点 1 也应读取共享 SPFILE 中的新配置，但仍建议分别登录两个节点进行核实。

截至本次处理结束，两个实例均为 OPEN / ACTIVE，数据库日志没有发现新的异常报错。

至此，本次参数调整和数据库恢复工作完成。

这次故障最终说明了什么？

这次排查有几个地方值得记录。

首先，遇到 Oracle RAC 的 LMS Hang，不能看到 ORA-29770 就直接判断是网络故障。

这次 OSWatcher 没有发现明显的 CPU、内存、I/O 和私网异常，真正值得关注的是故障时间段内的 DRM 资源重配置和 LMS 进程调用栈。

其次，Oracle Support 的判断也不一定意味着根因已经得到证明。

本次工程师高度怀疑 Ticket 耗尽，但由于版本较老，Trace 没有提供足够的诊断信息，因此只能把它作为重点怀疑方向。

最后，隐藏参数变更不能只关注 SQL 是否执行成功。

对于生产 RAC，参数调整之前不仅要确认参数含义，还要确认它们是否允许新旧配置在集群中短时间共存。

目前两个实例运行正常，日志没有新的异常，但这只能说明变更实施成功，尚不能证明 ORA-29770 已被彻底解决。

后续仍需观察 LMS、LMON、DRM 相关日志，以及 GC 等待和业务响应时间。

另外，当前 Oracle 11.2.0.4 版本较老，两个 DB Home 的补丁清单也未显示已安装的 Interim Patch。Oracle Support 建议参考 Database 11.2.0.4 Proactive Patch Information（KB111315），评估可获取的最新 PSU。

参数调整属于当前的风险规避措施，补丁升级和后续版本规划仍然需要单独推进。

写文章之外，我也在持续完善自己的数据库学习与运维平台 ORA100。

平时整理的数据库实战案例、常用 SQL、运维脚本和实用工具，都可以在这里找到。

网站地址：ora100.com

感兴趣的话，可以来看看。