ora-29740是节点被css主动驱逐的直接证据，源于连续misscount次未收到心跳；需同步调整misscount与disktimeout（且disktimeout>misscount），并优先排查lmon和cssd日志中的ipc卡顿、磁盘i/o饱和或ocssd.bin进程异常。
ORA-29740 是节点被驱逐的直接证据
只要日志里出现 ORA-29740: cluster member death detected，基本能断定是心跳链路异常触发了驱逐。这不是磁盘坏了或网络分区误判，而是 CSS 在连续 misscount 次未收到对端心跳后主动动手。这个值不是“容忍延迟”，而是“允许丢包次数”——每次心跳周期（默认 1 秒）算一次机会，丢满就踢人。
默认 misscount=30，理论最大中断容忍≈30秒，但实际远小于此，因为心跳不严格按秒发出。调高它不会让集群更稳，反而延长故障发现时间，增加脑裂风险；调低又容易把瞬时抖动当死亡，尤其在 ASM I/O 波动或 CPU 高负载时。
查当前值别信文档，必须现场确认
Oracle 安装或打补丁后，misscount 和 disktimeout 可能被隐式重置或继承自 profile。不能假设“没改过就是默认值”。最可靠的方式是现场执行：
crsctl get css misscount<br>crsctl get css disktimeout
注意：disktimeout 单位是毫秒，默认 200ms，它和 misscount 没有换算关系，二者独立作用：一个管“听不见邻居”，一个管“摸不到票箱”。
调整必须同步改，且满足 disktimeout > misscount
misscount 和 disktimeout 必须一起调，否则会出问题。比如只调大 misscount 而 disktimeout 还是 200ms，那磁盘心跳永远来不及响应，节点必然被误驱逐。
- 生产环境推荐组合（虚拟化或跨机架部署）：
misscount = 60，disktimeout = 300 - 修改命令：
crsctl set css misscount 60、crsctl set css disktimeout 300 -
misscount修改需重启 CSSD（crsctl stop crs && crsctl start crs），disktimeout热生效，但新值仅对后续 I/O 生效
调参只是延缓，根因必须查 LMON 和 CSSD 日志
调 misscount 不解决底层抖动源——90% 的案例根因在私网 CRC 错误、voting disk I/O 延迟或 ocssd.bin 进程卡死。
先看被驱逐节点的 lmon trace：/oracle/app/diag/rdbms/<db_name>/<instance_name>/trace/<instance_name>_lmon_<pid>.trc</pid></instance_name></instance_name></db_name>，搜索 ORA-29740、evicted by instance、inconsistent instance membership。若出现 IPC Receiver dump detected 或大量 minact-scn: useg scan erroring out，说明实例内部已严重卡顿，驱逐是结果而非原因。
再查 $GRID_HOME/log/<hostname>/cssd/ocssd.log</hostname>，真正驱逐前必有 node eviction initiated 或 Eviction initiated for node X，紧跟着 rebooting node X。如果日志里同时出现 Lost 2 disk heartbeats，比单纯网络丢包更危险，大概率是 ASM 磁盘组 I/O 饱和（iostat -x 1 查 %util > 95 或 await > 50ms）。
真正复杂的是：当 missed checkins 同时出现在网络和磁盘路径，但 node eviction initiated 滞后很久才出现，大概率是 ocssd.bin 自身卡住（CPU 占满、OOM Killer 杀掉进程），得结合 dmesg -T | grep -i kill 和 ps -ef | grep ocssd.bin 验证。
