oracle 11g rac节点频繁自动重启源于网络心跳超时触发驱逐，核心依据是ocssd.log中crs-1611→crs-1610→crs-1607递进日志；需检查私网配置、haip、网卡收包异常及底层网络抖动。
直接看 ocssd.log 里有没有 CRS-1611/CRS-1610/CRS-1607
别先翻 alert.log 或系统日志——那些是驱逐发生后的“判决书”，不是“案发现场”。真正决定节点生死的判断全在 ocssd.log 里。
-
CRS-1611表示该节点已连续丢失 75% 心跳，后面带的时间（如in 6.512 seconds）越小，说明恢复窗口越窄，问题越紧急 -
CRS-1610是临界警告：丢失 90%，再撑不住就要踢人；若只有一侧报这个、另一侧没报CRS-1612（this node was evicted by node X），大概率是本端收包异常，比如网卡rx_discards非零或中断风暴 -
CRS-1607是最终通告：驱逐已触发，节点即将重启；此时crsctl stat res -t会失败，但crsctl stat res -t -init还能看到底层资源状态
多节点同一时间段密集打出这三类日志，基本可排除单点故障，指向底层网络抖动或配置错位。
确认私网接口是否被 GPnP 正确注册
改过私网网卡名（如从 eth1 换成 eth2）或 IP 后 HAIP 起不来，根本原因就是 GPnP 配置没同步更新。HAIP 不认你手动配的 IP，只认 GPnP 里注册的 cluster_interconnect 接口。
- 先查当前识别的私网接口：
$GRID_HOME/bin/oifcfg getif -global，输出必须含cluster_interconnect标记 - 若显示旧网卡（如
eth1/100.100.100.0:cluster_interconnect），必须重设：$GRID_HOME/bin/oifcfg setif -global eth2/10.10.10.0:cluster_interconnect - HAIP 地址段固定为
169.254.0.0/16，不能手动指定；修改后必须停集群再启：crsctl stop crs→ 等所有进程退出 →crsctl start crs；不能只重启ohasd
区分网络心跳丢包和磁盘心跳失败
ORA-29740 是结果，不是原因。它只告诉你“节点被踢了”，但不告诉你为什么被踢。真因藏在 ocssd.log 的细节里：
- 搜
IPC Send timeout detected或network heartbeat failure→ 指向私网问题（交换机 ACL、MTU 不一致、网卡驱动缺陷） - 搜
disk heartbeat failed、vote file或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验证
别盲目调 misscount，先看 lmon trace
调大 misscount 只是延长容忍时间，不解决底层抖动源。90% 的频繁驱逐根因在私网 CRC 错误、voting disk I/O 延迟或 ocssd.bin 进程卡死。
-
lmontrace 比alert.log更早、更直接反映驱逐动因，路径：/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，说明实例内部已严重卡顿，需排查 SGA 压力、_lm_tickets是否过小（SGA > 100GB 时建议设为 5000）或共享内存参数不足
真正容易被忽略的是：驱逐前的“沉默期”——ocssd.log 里反复出现 missed heartbeat from node X 不等于已被驱逐；必须看到 node eviction initiated 或 Eviction initiated for node X 才算真正触发。而在这之前，可能已有数分钟的间歇性丢包未被记录，得往前翻更早的日志段。
