必须查ocssd.log中node eviction initiated标记，它是驱逐启动的第一手证据；若仅见missed heartbeat而无该标记，则属瞬时抖动；时间戳须早于系统重启记录，且需同步验证私网双工、haip状态及voting disk i/o稳定性。
查 ocssd.log 里是否真触发了 node eviction initiated
别只扫 alert.log 或系统日志——真正驱逐动作由 ocssd.bin 执行，它的日志才是第一手证据。路径是 $GRID_HOME/log/<hostname>/cssd/ocssd.log</hostname>，重点搜这三类标记：
-
node eviction initiated：驱逐已启动，节点还没重启，但已退出集群通信环 -
rebooting node X：驱逐完成，即将强制重启 -
misscount exceeded或disk timeout：明确指出是网络心跳断连还是表决盘 I/O 超时
若只看到 missed heartbeat from node X 却没后续 eviction，大概率只是瞬时抖动，不是真驱逐。时间戳必须早于系统 dmesg 里的重启记录，否则就是结果而非原因。
确认是不是私网双工不匹配或 HAIP 没起来
私网链路看似 UP，实际可能因交换机端口双工协商失败导致心跳包静默丢弃——这是 11g–19c 都高频复现的底层根因，比网卡故障更隐蔽。
- 登录交换机查真实双工状态：
show interfaces gigabitethernet X/X/X（Cisco）或display interface GigabitEthernet X/X/X（华为），确认Duplex: full且auto-negotiate: on - 在节点上执行
ip a | grep 169.254，无输出说明ora.cluster_interconnect.haip资源根本没起来；此时crsctl start res ora.cluster_interconnect.haip会报错 - HAIP 启不来，往往因为 GPnP 配置没同步：用
oifcfg getif -global看当前注册的私网接口，若仍是旧网卡（如eth1/10.10.10.0:cluster_interconnect），必须用oifcfg setif -global eth2/10.10.10.0:cluster_interconnect重设
改完必须停启集群：crsctl stop crs → 等所有进程退出 → crsctl start crs；只重启 ohasd 无效。
验证 voting disk I/O 是否真的稳定
磁盘心跳比网络心跳更“慢但可靠”，一旦它超时（disktimeout 默认 200 秒），节点几乎必被驱逐，且调大 disktimeout 只是拖延，不解决 IO 延迟本身。
- 用
crsctl query css votedisk确认表决盘路径和状态，再ls -l核对属主是grid:oinstall、权限是640 - 如果是 ASM 磁盘组，运行
asmcmd lsdsk -k -G <dg_name></dg_name>确保磁盘在线且MOUNTED - 直接测裸设备延迟：
dd if=<vote-device> of=/dev/null count=1 bs=4k 2>&1</vote-device>，留意耗时是否稳定在毫秒级；若单次 > 50ms 或波动剧烈，iostat -x 1查%util > 95或await > 50
注意：表决盘 IO 不稳时，ocssd.log 里常伴随 CRS-1606 或 voting file I/O error，不是网络问题，别往私网配置上瞎调。
别急着改 misscount，先看 LMON trace 有没有实例级卡死
misscount 是容忍窗口，不是病因。90% 的案例中，调大后仍被驱逐，是因为 lmon 进程自己先卡死了，或者实例内部已严重失步。
- 定位被驱逐节点的
lmontrace：$ORACLE_BASE/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）
真正危险的信号是：其他节点日志里 node eviction initiated 出现得很晚，但本节点的 lmon trace 早已中断——这意味着 ocssd.bin 或 lmon 自身被 OOM Killer 杀掉，或 CPU 占满假死，得结合 dmesg -T | grep -i kill 和 ps -ef | grep ocssd.bin 验证。
