ORA-29740 表示集群层CSS主动驱逐节点，是心跳失联的结果而非原因；常见诱因包括网络IPC超时、磁盘心跳失败、Oracle Bug或底层资源瓶颈，需结合ocssd.log与alert.log时间线综合分析。
ORA-29740 出现在 alert.log 里，基本就是节点被驱逐了
这个错误不是数据库层的业务报错，而是集群层（css）主动踢人的信号。它总出现在 reconfiguration started 前后，且伴随 evicting instance x from cluster 或 this node was evicted by node y。关键点在于：ora-29740 是结果，不是原因——它说明集群已判定该节点“失联”，但没告诉你为什么失联。
常见诱因包括：
- 网络心跳超时（
IPC Send timeout detected出现在同一时间点附近） - 磁盘心跳写入失败（
disk heartbeat failed或missed disk heartbeat在ocssd.log中） - Oracle 已知 Bug（如 11.2.0.3/4 在 Solaris 或高负载 Linux 下的 CSSD 进程竞争）
看到 ORA-00481，立刻查 lmon 进程和 ocssd.log
ORA-00481: LMON process terminated with error 意味着集群最核心的全局资源协调进程挂了。LMON 依赖 CSSD 提供的成员状态，一旦 CSSD 异常或通信中断，LMON 就会退出，进而触发实例级终止。这不是孤立事件，它几乎必然对应着 ocssd.log 中更早的异常。
检查 ocssd.log 的重点位置：
- 搜索
IPC timeout、network heartbeat failure—— 指向私网问题 - 搜索
disk heartbeat、vote file、missed heartbeat—— 指向 ASM 或存储 I/O 延迟 - 注意时间戳：如果
ocssd.log报错时间晚于节点重启时间，说明它只是“事后记录”，得往前翻更早的日志段
Alert Log 里反复出现 “Waiting for clusterware split-brain resolution”
这行日志是典型的心跳双断征兆：节点既收不到其他节点的网络心跳，也写不进投票盘（voting disk），自己无法确认是否真被隔离，只能僵住等待仲裁。此时集群已进入“疑似脑裂”状态，后续大概率触发驱逐。
它背后的真实瓶颈往往藏在底层：
- 私网交换机丢包、端口震荡、MTU 不一致（尤其 VMware 环境中虚拟网卡混用 e1000/vmxnet3）
- 共享存储响应慢（
iostat -x 1查看 %util 和 await 是否持续 >50ms） - 防火墙或安全组误拦截 UDP 通信（RAC 私网默认走 UDP，端口范围通常为 12500–12600）
别只盯 alert.log，ocssd.log 和 oclsomon.log 的时间线必须对齐
很多人只扫 alert.log 就下结论，结果绕远路。真正决定节点命运的是 ocssd.bin 进程的状态。它的日志（$GRID_HOME/log/<node>/cssd/ocssd.log）才是第一手证据。而 oclsomon.log 则反映 CSSD 是否被系统资源卡住（比如 CPU 被占满导致心跳线程无法调度）。
排查时务必做三件事：
- 用
date命令确认所有节点系统时间误差 - 用
crsctl check css和crsctl check crs看当前状态，别只信进程是否存在 - 对比各日志中“Reconfiguration started”那行的时间戳，找出最早异常发生的节点和模块
复杂点在于：一次驱逐可能是多个因素叠加的结果，比如先有网络抖动触发 CSSD 高频重试，再引发 I/O 堆积，最终让 oclsomon 判定 ocssd “not responding”。单看任一文件都容易误判。
