如何排查RAC节点被驱逐Eviction_CSS日志与宕机重启原因分析

ocssd.log 是诊断节点驱逐的首要日志，需优先检查"misscount exceeded"（私网心跳中断）或"disk timeout"（表决盘I/O失败）等关键错误，并确认时间同步、表决盘可达性及ocssd.bin崩溃信号。看 ocssd.log 里有没有 "misscount exceeded" 或 "disk timeout"节点被驱逐，ocssd.bin 是最终执行者，它的日志最直接。别急着翻 alert.log 或系统日志，先去 $grid_home/log/<hostname>/cssd/ocssd.log 找关键线索。如果看到 misscount exceeded、network heartbeat failure 或类似提示，基本锁定是私网通信中断或延迟超标（默认 misscount=30 秒，即连续 30 次没收到心跳）如果看到 disk timeout、voting file I/O error、CRS-1606，说明磁盘心跳失败，问题出在表决盘（voting disk）的读写上，可能是 ASM 延迟、存储链路抖动、裸设备权限错，或触发了 Bug 13869978（11.2.0.3.4 之前版本高发）注意时间戳：必须确认日志报错时间早于节点重启时间；否则就是"后见之明"，不是真因查网络心跳前先确认时间同步是否真实可靠时间不同步会直接导致 CSS 认为心跳超时------哪怕网络完全正常。CTSS（Cluster Time Synchronization Service）日志里出现异常返回值，或者 ntpq -p 显示 offset > 1000ms（比如你见过的 11376 ms），就已是强信号。别只改 NTP 配置：BIOS 时间也得同步，否则重启后又漂移检查时间源是否指向新环境的 NTP 服务器，旧数据中心的时间源在新网络下可能不可达或响应极慢crsctl check ctss 返回 ACTIVE: time synchronizer active 才算真正生效；若为 INACTIVE，CTSS 实际已退化为"观察模式"，不干预但也不校正用 crsctl query css votedisk 和 dd if=<vote-device> of=/dev/null count=1 bs=4k 验证表决盘可达性表决盘不是"配好就行"的静态配置，它每秒都在被读写。很多驱逐看似突发，实则是某块投票盘 I/O 卡顿超过 200 秒（disktimeout 默认值），CSSD 主动自毁保数据。 WisPaper 复旦大学研发的AI学术搜索工具，5分钟内筛选1000篇论文