CRS-1607是节点驱逐结果而非写入错误，表明CSSD已因私网心跳彻底丢失执行eviction；真正需关注的是驱逐前的CRS-1611（75%丢包）和CRS-1610（90%丢包）递进告警，结合多节点ocssd.log时间对齐、ethtool -S、arp -n及cluvfy校验定位底层网络或驱动问题。
CRS-1607不是写入错误，是节点驱逐结果
直接说结论：CRS-1607 本身不表示“写入失败”，而是 CSSD 进程判定私网心跳彻底丢失后执行的**节点驱逐（eviction）动作**，日志里那句 node <n> evicted</n> 是结果，不是原因。你在日志里看到它，说明驱逐已经完成，此时再查“写入错误”就错了方向。
真正要盯的是驱逐前的递进告警：CRS-1611（75%心跳丢失）、CRS-1610（90%丢失），它们才暴露底层问题。只盯着 CRS-1607 处理，等于救火后才找打火机。
查 ocssd.log 必须按时间桶比对多节点日志
单看一个节点的 ocssd.log 容易误判。比如节点1报 CRS-1612: this node was evicted by node 2，但节点2日志里根本没有对应时间窗口的 CRS-1610，那基本可断定是节点1自身收包异常，不是网络互通问题。
- 用
grep -i "crs-161[012]" /oracle/11.2.0/grid/log/<hostname>/cssd/ocssd.log | tail -50提取最近关键行 - 重点看每条记录末尾的时间值，如
in 6.512 seconds—— 数值越小，丢包越严重，恢复窗口越窄 - 把两个节点的日志按分钟级时间戳对齐，确认是否同步密集出现三连报错（1611→1610→1607）
物理层排查不能跳过 ethtool -S 和 arp -n
很多人只跑 ping 或 traceroute，但私网抖动往往藏在驱动层。网卡看似 up，实际已开始丢包或重传。
- 执行
ethtool -S eth2 | grep -E "(rx_discards|rx_errors|tx_carrier_errors)"（替换为你的私网接口名）—— 若rx_discards非零，说明内核已主动丢弃收到的包 - 执行
arp -n | grep <peer_ip>看 ARP 条目是否稳定；若频繁变动或显示INCOMPLETE，说明底层二层通信已不稳定 - 检查交换机端口：确认私网链路两端都强制设为全双工、速率一致，禁用 auto-negotiation（RAC 私网严禁协商）
别信 crsctl check cluster -all 的“在线”假象
crsctl check cluster -all 返回 CRS-4537: Cluster Ready Services is online 只代表进程活着，完全不反映私网心跳质量。它不测延迟、不统计丢包、不验证 GC 流量可达性。
真正有效的检查命令只有两个：
-
olsnodes -s -n -i：确认所有节点状态为Active且 IP 显示正确（不是 127.0.0.1） -
cluvfy comp nodecon -n all -verbose：这是唯一能真实探测私网连通性、MTU、ARP 响应和防火墙策略的校验工具，必须跑完且无 ERROR 级输出
修复 CRS-1607 的本质，是让 CSSD 在 6.5 秒窗口内稳定收到心跳包。任何绕过物理层、网络层、驱动层的“参数调优”都是临时止痛——网卡收不到包，再调 _css_heartbeat_timeout 也没用。
