Oracle RAC集群依赖节点之间的私网心跳来感知彼此的存活状态。一旦私网出现抖动，节点在心跳投票窗口内无法完成正常通信，集群就会认为对方节点出现故障，进而触发脑裂仲裁流程， surviving节点会争夺集群控制权，被驱逐的节点实例直接重启，轻则业务会话中断，重则整个集群连环重启。脑裂是RAC运维中最危险的故障之一，而网络抖动恰恰是最常见的诱因。要彻底解决这类问题，必须先弄清楚心跳仲裁的工作原理，再结合日志定位抖动根源，最后从参数、网络架构两个层面做加固。
一、RAC心跳机制与脑裂产生的原理
RAC集群的集群就绪服务（CRS）通过两种心跳维持集群成员关系：一种是节点间的网络心跳，走私网链路；另一种是磁盘心跳，通过投票盘（Voting Disk）实现。网络心跳正常时，节点间每隔约1秒发送一次心跳报文。当某个节点在misscount时间内（默认30秒，11g之后通常为30秒或60秒）没有收到对方心跳，CSS服务就会将该节点标记为missing，随即启动磁盘心跳仲裁。
脑裂仲裁的核心逻辑是：所有可达的节点通过投票盘进行投票，拥有更多集群成员资格（也就是投票盘上票数更多的一方）的节点组存活，票数少或完全失去投票盘访问能力的节点被驱逐。驱逐方式取决于配置：如果启用了IO隔离，被驱逐节点会被强制重启，防止其对共享存储继续写入造成数据损坏；如果IPMI等隔离手段不可用，节点可能会自行重启CSS甚至整个操作系统。
问题的关键在于，网络抖动会让节点短暂失去网络心跳，但抖动往往只有几百毫秒到几秒。如果抖动恰好与心跳判断窗口重叠，或者抖动频繁到让心跳长期丢包，集群就会反复进入仲裁流程。更糟糕的是，抖动通常是双向的，两个节点可能同时认为对方失联，各自发起投票，最终触发节点驱逐甚至连环重启。这就是为什么一次看似轻微的私网抖动，会演变成整个RAC集群的脑裂事故。
二、如何通过日志和参数确认脑裂由网络抖动引起
排查的第一步是查看集群告警日志和CSS日志，路径通常位于$GRID_HOME/log/节点名/alert节点名.log以及cssd/ocssd.log。典型的抖动型脑裂日志中会出现类似如下记录：
[CSSD][1234]clssgmPollingThread: node 2 (node2) has missed 3 of its last 5 heartbeats [CSSD][1234]clssscSelectMaster: network scratch resolution in progress [CSSD][1234]clssgmDiscardNode: node 2 (node2) has been evicted
看到missed N heartbeats就说明网络心跳确实出现过丢包，而不是节点真的宕机。如果日志里同时出现磁盘心跳正常的记录，基本可以锁定问题出在网络层。此时还要确认几个关键参数的当前值：misscount（网络心跳超时阈值）、disktimeout（磁盘心跳超时阈值，默认200秒）以及reboottime。可以通过如下命令查看：
crsctl get css misscount crsctl get css disktimeout crsctl query css votedisk
除了数据库日志，操作系统层面的证据同样重要。可以在所有节点部署ping监控脚本，持续探测私网对端地址并记录延迟，观察抖动发生时刻与CSS驱逐时刻是否吻合。同时检查交换机端口计数器，重点关注CRC错误、丢包、input error等指标。如果网卡做了bond或使用了HAIP，还要确认绑定模式是否稳定。私网流量过高也是一个常见诱因，例如应用误将私网地址用于业务通信，或者缓存融合流量激增挤占了心跳带宽。
三、网络抖动的常见根源与排查方法
抖动的来源大体分为三类。第一类是硬件与链路问题，包括网线或光纤老化、光模块功率衰减、交换机端口故障、网卡驱动缺陷等，这类问题往往伴随链路层错误计数增长。第二类是资源配置问题，例如私网与业务网共用交换机、私网带宽不足、流控配置不当导致的心跳报文排队延迟。第三类是主机层面的干扰，比如网卡中断都压在单个CPU上导致软中断处理延迟、内核参数不合理、防火墙对UDP心跳包做深度检测等。
排查时建议按顺序执行：先在两节点间用大包持续ping（例如ping -s 8972），观察是否有规律性延迟尖刺；再用ethtool -S检查网卡收发错误统计；然后登录交换机查看端口日志和错误计数。对于心跳延迟，Oracle还提供了-oraperf方式（通过oprocd或直接看oswatcher数据）辅助定位。很多生产事故的根因其实很朴素，比如私网交换机的一块板卡缓存溢出，或者HAIP漂移到故障网卡上，定位到具体设备问题后更换或调整即可解决。
一个容易被忽视的点是GC流量与心跳争抢。RAC的缓存融合走的是私网，当某个SQL引发大量块传输时，私网瞬时带宽被打满，心跳报文被排队丢弃。此时可以借助AWR报告中的gc相关的等待事件（如gc block lost、gc cr block 2-way耗时）来判断私网是否存在拥塞。如果gc block lost持续出现，几乎可以断定私网丢包，需要从应用SQL优化和网络扩容两方面入手。
四、加固方案：从参数调整到网络架构优化
短期止血可以适当调大misscount，让集群对短暂抖动更有容忍度，但要注意misscount调大后脑裂判定的整体时间也会变长，必须与磁盘心跳参数匹配。参数调整示例如下：
# 将网络心跳超时调整为60秒（需在维护窗口执行，两个节点都会滚动重启CSS） crsctl set css misscount 60 # 确认磁盘心跳超时大于misscount，通常保持200秒不变 crsctl get css disktimeout
参数只是缓冲手段，根治还是要靠网络架构。首先是私网物理隔离，心跳网络务必使用独立交换机，不要与业务网混用。其次建议部署冗余私网链路，11g及以上版本使用HAIP自动管理多个私网地址，19c则可以直接采用更大带宽的私网并配合bond做链路聚合。交换机侧应关闭私网端口的流量突发限制，开启jumbo frame（MTU 9000）以提升缓存融合效率，同时确保两节点MTU配置一致，否则大包分片失败同样表现为抖动。
主机层面可以做几件事：确认网卡中断分布合理，必要时做irqbalance调优；关闭私网接口上无用的防火墙规则，心跳UDP包不做深度检测；部署nmon或OSWatcher常态化采集网络指标，为后续故障复盘提供数据。最后建议定期做脑裂演练，在测试环境人为制造私网中断，验证驱逐顺序、服务漂移和IPMI隔离是否按预期工作。只有把心跳机制理解透、把网络架构做扎实，RAC集群才能真正扛住网络抖动的冲击。
Oracle RAC脑裂网络抖动修改时间：2026-09-15 13:51:44