LMON进程本身不检测死锁，死锁告警由LMD触发；若LMON出现hang、deadlock字样或stuck状态，表明RAC全局资源协调层已失稳，需立即检查GES状态、私网连通性及CRS日志。
LMON 进程本身不检测死锁，也不生成死锁告警——你在 alert.log 里看到的 “Global Enqueue Services Deadlock detected” 是 LMD（Lock Manager Daemon）触发的，但日志中若出现 LMON 相关异常（如 LMON hang、LMON trace 中含 DEADLOCK 字样、或 LMON 被标记为“stuck”），说明全局锁协调已陷入底层阻塞，此时死锁不是孤立事件，而是 RAC 集群资源协调层已失稳。必须跳过常规 kill session 流程，直查 GES 层状态与 LMON/LMD 协同瓶颈。
确认是不是真 LMON 异常，还是 alert 误读
很多 DBA 看到 alert 里带 “LMON” 就紧张，其实 Oracle 告警日志中常见混淆点如下：
- 告警行写的是
Global Enqueue Services Deadlock detected. More info in file .../lmd0_*.trc→ 实际是LMD检测并 dump，和LMON无关 - 如果 alert 或 ADR 中出现
LMON+deadlock/hang/missed heartbeat/reconfiguration failed→ 才是真正 LMON 层问题，需立即干预 -
LMONtrace 文件名固定为instN_lmon_*.trc，不是_lmd0_或_ora_；grep"DEADLOCK"在lmon_*.trc中几乎不会命中，命中即属严重异常
查 LMON 是否真卡住：用 OS 和实例级信号交叉验证
LMON 卡住最直接的表现是集群 reconfiguration 长时间挂起、节点驱逐（eviction）失败、或 gv$instance 状态异常。不要只信 SQL 查询结果：
- 在每个节点执行：
ps -ef | grep "lmon" | grep -v grep—— 若输出为空或进程状态为T（stopped），说明 LMON 已终止或被内核冻结 - 检查 CRS 日志：
tail -50 $GRID_HOME/log/`hostname`/crsd/crsd.log，搜索LMON、reco、evict，看是否有 “failed to get LMON heartbeat” 类报错 - 查实例是否仍注册进 clusterware：
crsctl stat res -t | grep -E "(DATABASE|INSTANCE)"，若某实例显示OFFLINE但数据库进程仍在，大概率 LMON 失联 - 在数据库内快速验证：
SELECT inst_id, startup_time, status FROM gv$instance;—— 若某实例status为UNKNOWN或长时间无更新，LMON 可能已 hang
LMON 异常时，别急着 kill session，先保集群心跳
LMON 不是普通后台进程，它负责维护实例间 membership、协调 GES/GCS 全局资源状态同步。一旦异常，ALTER SYSTEM KILL SESSION 可能根本无法广播到其他节点，甚至让 LMD 更混乱：
- 禁止在疑似 LMON hang 的实例上执行任何 DDL、大事务提交或
ALTER SYSTEM类命令 - 若仅单节点 LMON 异常，且 CRS 未自动重启该实例，可手动尝试：
srvctl stop instance -d <db_name> -i <inst_name>，再srvctl start instance—— 这比杀会话更安全 - 若 LMON trace 中反复出现
waiting for node <n> to respond，且对应节点 CRS 状态异常，优先排查私网连通性：ping -I <private_if> <other_node_private_ip>+oifcfg getif核对 cluster_interconnects 配置 - 切勿修改
_lm_dd_interval或重启 LMD 进程来“修复”——LMON hang 时，LMD 依赖 LMON 的 membership 通知，强行干预可能引发脑裂
LMON trace 里真正要盯的三类线索
lmon_*.trc 文件极难读，但以下字段出现异常组合，基本可判定故障根因：
-
*** LMON RECONFIGURATION STARTED ***后无*** LMON RECONFIGURATION COMPLETE ***→ 私网丢包或节点响应超时，重点查oifcfg和交换机 buffer -
Node <n> is missing heartbeat from node <m>且持续 > 3 次 → 不是网络抖动，是 CRS 或 OS 层已无法维持心跳，需检查crsctl check crs和系统负载（CPU saturation、memory pressure） -
GES resource cleanup failed for resource [TX-...]+holding instance <n>→ 表明 LMON 无法协调释放跨实例 TX 锁，此时v$ges_blocking_enqueue查询可能返回空或陈旧数据，必须结合归档日志用DBMS_LOGMNR追踪 XID 提交状态
LMON 层异常不是“慢一点的死锁”，而是集群信任链断裂的前兆。它的信号往往藏在 CRS 日志、OS 进程状态和私网连通性里，而不是 SQL_ID 或 v$session。处理优先级永远是：保节点存活 > 清理会话 > 还原业务 SQL。
