ORA-29740是集群驱逐结果而非原因，应优先检查ocssd.log中的IPC timeout或disk heartbeat failed；再结合alert.log中IPC Send timeout时间戳、lmon.trc连接状态及多节点日志交叉比对定位私网或存储问题。
ORA-29740 不是数据库故障，而是集群已判定该节点“失联”并执行驱逐——它永远是结果，不是原因。直接查 alert.log 里的这行报错，只会绕远路。
先看 ocssd.log 里有没有 IPC timeout 或 disk heartbeat failed
集群心跳靠两路：私网通信（IPC）和投票盘（voting disk）写入。哪一路断了，ocssd.log 都会先报错，时间通常比 alert.log 早几秒到几十秒。
- 搜
IPC timeout、network heartbeat failure→ 指向私网问题：交换机丢包、MTU不一致、UDP 12345 端口被防火墙拦截 - 搜
disk heartbeat、missed heartbeat、vote file→ 指向 ASM 或存储 I/O 延迟：ASM diskgroup offline、存储链路打满、multipath 切换卡顿 - 注意时间戳：如果
ocssd.log报错时间晚于节点重启时间，说明日志被覆盖或没刷盘，得往前翻至少 2 分钟的段落
alert.log 里出现 IPC Send timeout 就别等了
这个错误一出现，基本就进入倒计时。默认超时是 300 秒（5 分钟），之后 LMON 就会触发驱逐。你看到的 ORA-29740 往往是第 5 分钟末才写进日志，但问题在第 1 分钟就已经发生。
- 确认发送方和接收方：比如
IPC Send timeout to 2.2 inc 11表示实例 2 的进程发不出去；Receiver: inst 2 binc 1323620776表示实例 2 收不到 - 不是单向问题：A 发不出去，大概率 B 也收不到；别只盯一个节点的
alert.log，必须交叉比对所有节点的时间线 - 别信“网络 ping 通”：用
ping -I <private_if><other_node_private_ip></other_node_private_ip></private_if>测私网连通性，再加-f -s 8972测巨帧（如果 MTU=9000）
查 lmon_<pid>.trc</pid> 看 CSS 连接是否断开
lmon 是数据库实例里唯一跟 CSSD 打交道的进程，它通过本地 socket（如 /var/tmp/.oracle/sN）连 ocssd.bin。一旦这个连接卡住或断开，lmon 就会中止实例。
- 路径在
$ORACLE_BASE/diag/rdbms/<db_name>/<instance_name>/trace/</instance_name></db_name>，找最新生成的lmon_*.trc - 搜索
css client connect failed、css heartbeat timeout、failed to connect to CSS - 如果
ps -ef | grep lmon显示 PID 频繁变化，说明lmon被反复拉起又挂掉——这时ocssd极可能已不稳定，优先稳 GRID 层，别动 DB
真正难定位的，是那些不报错但持续微抖的私网延迟，或者 ASM diskgroup 因 I/O 队列积压导致的间歇性心跳丢失。这些不会立刻写 ERROR，但会在 ocssd.log 里留下 WARNING: missed heartbeat 或 slow disk heartbeat 这类线索——得手动翻，不能只依赖 grep ERROR。
