判断节点是否真被驱逐的唯一依据是ocssd.log中出现“Eviction initiated for node X”或“node eviction initiated”；alert.log中的ORA-29740仅表示实例被踢，不等于节点重启。
查 ocssd.log 里有没有 Eviction initiated for node X
这不是可选步骤，是判断“是否真被驱逐”的唯一依据。alert.log 里的 ORA-29740: evicted by instance number X 只说明实例被踢，不等于节点重启；只有 ocssd.log 中出现 Eviction initiated for node X 或 node eviction initiated，才代表 CSSD 主动发起节点级驱逐。
常见误判点：
- 只盯着 alert.log，漏掉
$GRID_HOME/log/<hostname>/cssd/ocssd.log的原始日志 - 在非被驱逐节点上查 ocssd.log —— 必须登录到“报错节点”本机查自己的日志
- 用 grep 模糊匹配时写成
evict，结果命中无关行（如evicting cache），应严格匹配完整短语
从 .trc 文件抓 kjb、kcb、kj 开头的函数调用栈
一旦确认是真驱逐，下一步不是翻系统日志，而是找对应时间点的 CSSD trace 文件。路径通常是：$GRID_HOME/log/<hostname>/cssd/ocssd.trc，或按时间戳命名的滚动文件（如 ocssd_20260915142211.trc）。
重点盯三类函数前缀，它们直接暴露故障模块：
-
kjb开头（如kjbrcvt、kjbrfnd）→ RAC 缓存融合（Cache Fusion）收发异常，大概率私网问题 -
kcb开头（如kcbzwfcro_2、kcbgcur）→ 数据块访问层故障，可能关联 voting disk I/O 延迟或 ASM 磁盘组损坏 -
kj开头（如kjxgrrcv、kjxgrqrcv）→ 全局队列服务（GES/GCS）底层通信失败，常与 IPC 或共享内存卡死有关
别通读整个 trace 文件。用 grep -A 5 -B 2 "kjb\|kcb\|kj" ocssd_*.trc | head -n 50 快速定位顶部几帧调用栈即可。
结合 iostat 和 netstat 验证 root cause
Trace 文件给出“模块线索”，但不能替代系统层验证。必须立刻做两件事：
- 查 voting disk 所在物理盘的 I/O：先用
crsctl query css votedisk确认投票盘位置，再用asmcmd lsdg和asmcmd ls -l定位到底层设备（如/dev/oracleasm/disks/VOL1），最后在对应节点跑iostat -x 1 5，盯%util > 95、await > 50ms、w_await持续飙升 - 查私网分片失败：运行
netstat -s | grep -i "reasm"或cat /proc/net/snmp | grep -i "ReasmFails"，若ReasmFails计数每分钟增长 > 10，说明私网已无法重组分片包，Cache Fusion 必断
注意：VMware 环境下，ReasmFails 高往往源于 MTU 不一致（一端 1500，另一端 1472）或未启用 disk.EnableUUID=true，这些不会在 trace 里体现，但会直接导致驱逐。
别跳过 dmesg 和 journalctl 的 OOM 杀手痕迹
很多“驱逐”其实是伪驱逐：CSSD 进程被 Linux OOM Killer 杀掉后，节点没来得及发心跳就僵死，CSSD 自己也挂了，于是其他节点判定它失联并驱逐。这种情况下，ocssd.log 可能没写完就中断，而 dmesg 或 journalctl 里会有铁证。
立即执行：
dmesg | grep -i "killed process" | grep -i ocssdjournalctl -b | grep -i "oom\|kill" | grep -i "grid\|ocssd"
如果输出中出现 Out of memory: Kill process <pid> (ocssd.bin)</pid>，那就不用再查存储或网络了——这是资源限制问题，要检查 /etc/systemd/system.conf 中的 DefaultTasksMax 是否仍为默认 512（需设为 infinity），以及 ulimit -u 对 grid 用户是否足够。
