ORA-29702本质是集群心跳中断，源于lmon进程无法与CSSD通信导致实例被驱逐；需优先检查ocssd.log、私网连通性、MTU一致性及UDP 12345端口防火墙规则。
ORA-29702 错误本质是集群心跳中断，不是数据库层问题
ora-29702 表示 oracle rac 实例无法与 cluster synchronization services（css）通信，lmon 进程检测到集群成员状态异常后主动终止实例。这不是 sql 或参数配置错误，而是底层集群基础设施失联——lmon 依赖 cssd（ocssd.bin）维持节点存活感知，一旦 cssd 不可用或网络隔离，lmon 就会报这个错并触发实例驱逐。
常见错误现象：ORA-29702: error occurred in Cluster Group Service operation 配合 LMON trace 中反复出现 css client connect failed 或 css heartbeat timeout；crsctl check cluster 显示部分节点 offline；olsnodes -s 输出不一致。
- 先别急着查数据库日志，直接看
$GRID_HOME/log/<node>/cssd/ocssd.log，重点搜ERROR和timeout - 确认
crsd.bin和ocssd.bin进程是否真实在运行：ps -ef | grep ocssd，注意 PID 是否持续变化（说明进程反复崩溃） - 检查私网（通常为
eth1或ib0）是否 up 且无丢包：ip link show <private_if>、ping -I <private_if> <other_node_private_ip> -c 5
lmon 进程挂起或反复重启的典型诱因
lmon 是数据库实例内唯一与 CSSD 交互的后台进程，它通过 IPC（通常是 /var/tmp/.oracle/sN 类 socket）连接本地 ocssd。一旦该通道断开或响应延迟超阈值（默认 30 秒），lmon 就会中止实例。
使用场景：RAC 启动阶段、私网抖动后、节点被临时隔离又恢复时最易触发。
-
lmontrace 文件路径是$ORACLE_BASE/diag/rdbms/<db_name>/<instance_name>/trace/lmon_<pid>.trc，搜索css和connect关键字可确认连接失败时间点 - 若
lmonPID 频繁变化（ps -eo pid,comm,etime | grep lmon），大概率是ocssd崩溃导致数据库进程被强制清理，此时应优先稳住 GRID 层 - 不要手动 kill
lmon或尝试 restart 数据库实例——这只会让问题更难复现；先停掉 DB，再用crsctl stop crs彻底停止 GRID 栈，排查后再启动
lms 进程状态异常其实是结果，不是原因
lms（Global Cache Service Process）负责跨节点缓存块传输，它依赖 lmon 提供的集群视图来判断哪些节点在线。当 lmon 失联 CSSD 后，lms 会进入等待或挂起状态（lms0 状态常为 SLEEP 或 WAITING），但这只是下游表现。
性能影响：如果仅单个节点出现 ORA-29702，其他节点的 lms 会持续重试向故障节点发送 GCS 消息，可能引发局部 GC 延迟升高，但不会导致整个集群不可用。
- 查
lms状态用ps -eo pid,comm,stat,etime | grep lms，状态为R（running）才正常；若长时间S（sleep）且 etime 很小，说明刚被拉起又卡住 -
select * from gv$process where program like '%LMS%';可看各节点lms的 SPID 和状态，但注意：该视图本身需要实例存活才能查，出错节点上执行会失败 - 不要单独重启
lms：它是 Oracle 自动派生的后台进程，重启实例或 CRS 才是有效手段
私网 MTU 不一致或防火墙拦截是最隐蔽的根因
很多团队查完物理链路和 IP 配置就放弃，其实 ORA-29702 在私网层面非常敏感：MTU 不匹配会导致 CSS 心跳包被分片，而某些交换机或防火墙会丢弃分片包；iptables 若未放行 UDP 12345（CSS 默认端口）或 ICMP，也会静默阻断心跳。
兼容性影响：Oracle 11.2+ 默认启用 udp 传输 CSS 心跳，12c 后支持 udp6，但混合 IPv4/IPv6 配置容易引发协商失败。
- 确认所有节点私网 MTU 一致：
ip link show <private_if> | grep mtu，推荐统一设为1500（避免 jumbo frame 引入不确定性） - 检查防火墙：
iptables -L -n -v | grep :12345，确保 INPUT/OUTPUT 链允许 UDP 到 12345 端口；如用 firewalld，确认publiczone 未启用或已加规则 - 验证 CSS 端口连通性：
nc -uz <other_node_private_ip> 12345（注意是-uUDP），不通则立刻查网络设备策略
真正麻烦的是那些“看起来通但偶尔丢包”的私网——比如共享交换机背板拥塞、网卡驱动 bug、或者虚拟化平台对 UDP 分片处理异常。这类问题往往要抓包（tcpdump -i <private_if> udp port 12345 -w css.pcap）才能定位。
