ora-29740是集群层css主动驱逐节点的结果而非原因，表明节点已被判定失联；需结合alert.log中的ipc超时、ocssd.log中的eviction标记及lmon trace中的驱逐动因综合分析。
ORA-29740不是数据库错误，是集群层驱逐信号
看到 ORA-29740 就去查 alert.log 里的 SQL 报错或事务回滚，方向就错了。这个错误只说明：CSSD 进程已判定该节点“失联”，并执行了强制隔离——它本身不告诉你为什么失联，只是结果。
真正要盯的是时间点前后 1–2 分钟内的三类日志：
-
alert.log中ORA-29740出现前的IPC Send timeout、Waiting for clusterware split-brain resolution -
$GRID_HOME/log/<hostname>/cssd/ocssd.log</hostname>里紧邻的node eviction initiated或Eviction initiated for node X - 被驱逐节点的
<instance_name>_lmon_<pid>.trc</pid></instance_name>（路径如/oracle/app/diag/rdbms/<db_name>/<instance_name>/trace/<instance_name>_lmon_14788.trc</instance_name></instance_name></db_name>），搜索evicted by instance和minact-scn: useg scan erroring out
先查 LMON trace 定位驱逐动因，别只看 alert.log
lmon 是实例级成员资格仲裁的核心进程，它的 trace 文件比 alert.log 更早、更直接记录驱逐逻辑。比如出现：
IPC Receiver dump detected. minact-scn: got error during useg scan e:12751 Detected an inconsistent instance membership by instance 1
说明实例内部已严重卡顿，lmon 主动放弃协调——此时驱逐是结果，不是起点。
常见线索及对应动作：
- 出现
IPC Receiver dump detected→ 检查本节点 CPU 是否持续 >90%、内存是否被 OOM Killer 杀过进程（dmesg -T | grep -i kill） - 大量
minact-scn: useg scan erroring out→ SGA 压力过大，确认_lm_tickets是否过小（SGA >100GB 时建议设为 5000） - trace 里有
kjxgrrcfgchk: Initiating reconfig, reason 3→ 原因代码 3 = “通信故障”，需立刻转向网络和存储排查
从 ocssd.log 判断是真驱逐还是心跳抖动误报
ocssd.log 里高频出现 missed heartbeat from node X 不等于节点已被驱逐。真正驱逐的铁证只有两行：
-
node eviction initiated或Eviction initiated for node X - 紧接着的
rebooting node X
如果这两行缺失，只是反复报 missed checkins，大概率是 ocssd.bin 自身卡死（比如 CPU 占满、线程阻塞），而非网络或磁盘问题。
关键区分点：
- 同时丢失
network和disk心跳，但node eviction initiated延迟出现 → 优先查ps -ef | grep ocssd.bin和top -p $(pgrep ocssd) - 只丢
disk heartbeats（日志含Lost 2 disk heartbeats）→ 立即跑iostat -x 1，看%util > 95或await > 50ms，重点查 ASM 磁盘组 I/O - 只丢
network heartbeat→ 检查私网交换机 CRC 错误、MTU 是否一致（尤其 VMware 中混用e1000/vmxnet3）、防火墙是否拦截 UDP 12500–12600 端口
调 misscount 和 disktimeout 是权宜之计，不是根治手段
misscount 默认 30（≈30 秒中断容忍），但它不是“延迟容忍值”，而是“允许连续丢包次数”；disktimeout 默认 200ms，只控制表决盘 I/O 超时，和网络心跳无关。
调整前必须确认底层稳定，否则只是掩盖问题：
-
disktimeout改大（如设为 500）却无法解决 ASM I/O 队列积压 → 后续仍会失败 -
misscount调高 → 故障发现变慢，脑裂风险上升；调低 → 把瞬时抖动误判为死亡，尤其在高负载下更易误驱逐 -
crsctl set css misscount <n></n>和crsctl set css disktimeout <ms></ms>必须同步改，且严格满足disktimeout > misscount，否则磁盘心跳永远来不及响应 - 改
misscount需重启 CSSD（crsctl stop crs && crsctl start crs），disktimeout可热生效但仅对后续 I/O 生效
最常被忽略的一点：misscount 和 disktimeout 的当前值不能靠文档或记忆，必须现场查——安装或打补丁后它们可能已被隐式重置。运行 crsctl get css misscount 和 crsctl get css disktimeout 才算数。
