Oracle RAC私网心跳丢失会按CRS-1611（75%丢包）、CRS-1610（90%丢包）、CRS-1607（节点驱逐）递进触发告警，多节点同期密集出现即表明底层网络抖动，需结合ocssd.log、ethtool、ping及IPCLW trace日志综合定位。
私网心跳丢失直接触发CRS-1611/1610/1607递进告警
oracle rac节点被踢出，绝大多数不是“突然宕机”，而是私网心跳连续丢失后，cssd进程按固定阈值逐级升级告警并最终驱逐。关键线索全在/oracle/11.2.0/grid/log/<hostname>/cssd/ocssd.log</hostname>里，不是看有没有报错，而是看三类错误是否密集、递进出现：
-
CRS-1611：75% 心跳包在指定窗口（如in 6.512 seconds）内未收到——这是第一道黄灯 -
CRS-1610：90% 心跳丢失，已逼近临界——红灯亮起，驱逐倒计时启动 -
CRS-1607：正式触发节点驱逐（eviction），日志里会明确写node <n> evicted</n>
若多个节点在同一分钟内都打出这三连报错，基本可排除单点故障，直接定位底层网络抖动；若仅一侧报 CRS-1612（this node was evicted by node X）而对端无对应 CRS-1610，大概率是本节点收包异常（网卡丢包、中断风暴），不是对端问题。
DIAG进程内存暴涨往往是私网不稳的副产物
19c+ 环境中，ora_dia0 进程内存飙升到 20G+ 并非独立故障，而是私网抖动引发 IPC 层重传风暴后的连锁反应。诊断时别急着 kill 进程，先查 ocssd.log 是否同期出现 CRS-1611 —— 若有，再翻 diag/rdbms/<db_unique_name>/<instance_name>/trace/</instance_name></db_unique_name> 下以 IPCLW: 开头的 TRACE 日志（如 IPCLW:[0.123777436]{E}[WAIT]:PROTO），这类日志大量涌现，说明 GC 流量因网络延迟反复重传，DIAG 被迫缓存大量待确认包，最终内存泄漏。
- 该现象在 MOS 文档
2787583.1中明确定义为私网性能问题导致，非数据库参数或 SQL 引起 - 人工
kill -9ora_dia0可临时释放内存，但若私网未修复，几小时内必然复现 - 真正根治必须结合
ethtool -S eth2 | grep -E "(rx_discards|rx_errors)"查物理层丢包，而非调大_gc_affinity_time等隐含参数
仅靠 crsctl check cluster -all 无法判断私网是否抖动
crsctl check cluster -all 返回 CRS-4537: Cluster Ready Services is online 只代表集群服务进程活着，不代表私网心跳稳定。它不探测毫秒级延迟、不统计丢包率，更不反映 GC 流量实际传输质量。真实抖动必须用底层工具交叉验证：
-
ping -c 100 -i 0.1：关注 >5ms 的包占比，RAC 私网要求 95% 包 ≤2ms；一旦 >5% 的包超过 5ms，gv$cr_block_server中的cr_busy%就会明显上扬 -
ethtool -S eth2中rx_discards或rx_errors非零，基本指向驱动缺陷、交换机 QoS 限速或光模块老化，和 Oracle 配置无关 -
netstat -s | grep -i "retransmit"：TCP 重传率持续 >1%，说明链路已不可靠，CSSD 心跳和 GC 流量都会受影响
很多 DBA 在节点驱逐后只查 crsctl status res -t，却漏掉 ping 和 ethtool 输出，结果反复排查 OCR 权限、voting disk 路径，白白浪费数小时。
diagcollection.pl 或 tfactl diagcollect -all 必须带时间范围
收集日志时用 tfactl diagcollect -all 是对的，但若不加 -from/-to 参数，它默认只采最近 2 小时——而节点驱逐前的私网抖动可能早在 3 小时前就开始了。更麻烦的是，diagcollection.pl（11g/12c 早期）生成的 crsData_*.tar.gz 和 oraData_*.tar.gz 是分离包，不手动合并就提交 SR，Oracle Support 会直接打回。
- 正确命令示例：
tfactl diagcollect -all -from "May/12/2026 20:00:00" -to "May/12/2026 22:30:00" - 采集前务必确认各节点
tfactl status显示 green，且 root 用户已配置 SSH 免密（ssh root@rac2能直连） - 解压后重点盯三个目录：
/crs/（含ocssd.log）、/asm/（OCR/voting disk 状态）、/database/<db_unique_name>/<instance_name>/trace/</instance_name></db_unique_name>（DIAG TRACE）
最容易被忽略的是：所有工具都不会自动采集 ocrcheck -details 和 crsctl query css votedisk 的实时输出，这两条命令必须人工执行并保存原始文本，否则 SR 审核时第一轮就被拒。
