节点被驱逐后，ocssd.log是唯一能还原心跳断点的日志，需重点检查crs-1611（75%丢包）、crs-1610（90%丢包）、crs-1607（正式驱逐）是否在时间上密集递进出现；多节点同步爆发指向底层网络抖动，单节点独发则优先排查本端物理层丢包或网卡异常。
节点被驱逐后，ocssd.log 是唯一能还原“心跳断在哪一环”的日志，不是看有没有报错，而是看 CRS-1611/1610/1607 是否密集、递进出现。
怎么看 ocssd.log 里的心跳丢包告警
直接在 /oracle/11.2.0/grid/log/<hostname>/cssd/ocssd.log</hostname> 中搜索三类错误，它们是按时间桶严格递进的：
-
CRS-1611：75% 心跳未收到，后面带的时间值（如in 6.512 seconds）越小，说明网络恢复窗口越窄，问题越紧急 -
CRS-1610：90% 心跳丢失，已进入驱逐倒计时，此时集群开始准备投票 -
CRS-1607：正式触发驱逐，日志明确写Node <n> is being evicted</n>
若多个节点在相同分钟内都打出这三连报错，基本可排除单点故障，直接指向底层网络抖动；若仅节点 A 报 CRS-1612: this node was evicted by node X，而节点 X 的 ocssd.log 里没有对应 CRS-1610，那大概率是节点 A 自身收包异常（网卡丢包、中断风暴），不是对端问题。
为什么不能只看 alert.log 或 crsd.log
alert.log 只记录结果（如 Reconfiguration started、GlobalResource Directory frozen），不体现原因；crsd.log 关注资源启停，和心跳丢失无直接关联。真正决定“该不该踢人”的是 ocssd.bin 进程，它的判断依据全在 ocssd.log 里。
- 网络心跳由
ocssd.bin每秒主动发包，超misscount（默认 30 秒）未收到即触发告警链 - 磁盘心跳也由
ocssd.bin定期写入 voting disk，但日志中不显式打印“disk heartbeat lost”，需结合CRS-1611是否伴随CRS-1614（磁盘 I/O 超时）来交叉判断 - 如果
ocssd.log里只有CRS-1611，没后续CRS-1610/1607，且很快恢复，说明是瞬时抖动；若反复出现三连报错，则必须查物理层
查到 CRS-1611 后下一步做什么
确认是网络问题后，别急着调 _gc_affinity_time 或改 misscount，先做底层验证：
- 跑
ethtool -S eth2 | grep -E "(rx_discards|rx_errors|tx_aborted_errors)"——只要非零，就是驱动、交换机 QoS 或物理链路问题 - 用
ping -c 100 -i 0.1看延迟分布：>5ms的包占比超过 5%，GC 等待就会明显上扬 - 检查是否私网 IP 被占用：
arping -I eth2 -c 3，若收到非本机响应，说明 IP 冲突，这是 11gR2 常见重启诱因 - 确认网卡绑定模式：
cat /proc/net/bonding/bond0，mode=1（active-backup）下主备切换失败也会导致心跳中断
真正关键的不是“有没有报错”，而是三类 CRS 错误是否在时间上紧密咬合、是否多节点同步发生——这决定了你该修网线，还是该调参数。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
