Oracle RAC的节点驱逐（Node Eviction）是集群管理中最高频也最容易误判的故障之一。表面上看起来是某个节点毫无征兆地重启了，实际上驱逐是Clusterware在检测到节点健康状态异常后，为了保护集群数据一致性而主动执行的自救动作。被驱逐的节点会执行重启（版本不同行为略有差异），如果根因没有找到，问题往往会反复出现。要彻底解决，必须先理解驱逐的判定机制，再按网络、存储、主机、数据库四个层面逐项排查。
一、节点驱逐的判定机制：CSSD如何决定踢掉一个节点
RAC集群中每个节点都运行着CSSD（Cluster Synchronization Service Daemon）进程，它负责维护集群成员资格。节点之间通过两种心跳交换存活信息：一种是网络心跳，走私有互联网络（interconnect），默认每秒一次；另一种是磁盘心跳，通过投票磁盘（Voting Disk）进行，用于网络心跳失效时的仲裁。当CSSD在misscount（默认30秒，11g后部分平台为60秒）时间内没有收到某节点的网络心跳，或节点在disktimeout（默认200秒）内无法完成磁盘心跳，就会判定该节点失联并触发驱逐。
驱逐本身分两种情形：一种是本节点CSSD发现自身无法与集群通信，主动执行自我重启，日志中通常表现为rebooting due to communication failure；另一种是被其他节点判定死亡后通过网络指令强制重启。11.2.0.2之后的版本引入了Agent框架和自我驱逐的细化分级，很多场景下节点会先尝试自我修复，只有无法恢复才真正reboot。理解这一点很重要：日志里出现的驱逐只是结果，真正的病灶可能在CSSD进程被饿死、心跳链路中断或投票盘响应缓慢等更底层的位置。
-- 查看当前集群的心跳相关配置 crsctl get css misscount crsctl get css disktimeout crsctl get css reboottime -- 查看集群节点状态与投票盘信息 crsctl query css votedisk olsnodes -s -t
一个常见误区是把misscount调大来掩盖问题。如果心跳延迟的根因是主机严重swap或IO hang，调大参数只会延后驱逐发生的时间，并不能避免故障，甚至可能在脑裂（Split Brain）风险上留下隐患。参数调整必须建立在根因明确的基础上。
二、网络与存储层面：心跳链路是最常见的诱因
统计实际案例，网络问题占RAC驱逐原因的相当大比例。私有网络抖动、交换机故障、网卡驱动缺陷、bonding配置不当，都会导致网络心跳在misscount窗口内丢失。排查时要重点关注gi_home/log/节点名/alert节点名.log中的驱逐记录前后时间段，通常会看到类似misscount 30 has expired或network is not communicating的提示。配合OSW（OS Watcher Black Box）的netstat、slinux数据归档，可以还原故障时刻私有网络的丢包和重传情况。此外，如果互联网络经过了非专用交换机，或与其他业务流量共享带宽，大流量传输引发的网络延迟同样可能触发驱逐，这也是Oracle强烈要求interconnect使用独立高速网络的原因。
磁盘心跳问题同样不可忽视。存储阵列响应缓慢、多路径软件切换超时、Voting Disk所在LUN的IO延迟超过disktimeout，都会让节点被判定为异常。值得注意的细节是：如果Voting Disk放在ASM磁盘组中，而该磁盘组同时还承载OCR和数据文件，一旦存储出现整体性IO hang，磁盘心跳与业务IO会同时受害，问题会表现为数据库层面大量enq等待与节点驱逐并存。排查存储问题时，除了查看alert log中的Waiting for DVIO类记录，还应结合存储侧的性能数据和主机端的iostat、多路径日志一起分析。
# 检查私有网络配置与丢包情况 netstat -s | grep -i -E "retrans|drop" ifconfig -a | grep -A1 bond # 查看GI告警日志中的驱逐相关记录 grep -i -E "evict|misscount|reboot" $GRID_HOME/log/`hostname -s`/alert`hostname -s`.log # 检查投票盘IO响应 crsctl query css votedisk crsctl stat res -t
三、主机资源与数据库进程：被忽视的软件层杀手
很多驱逐案例最终定位到的是主机资源问题而非硬件故障。最典型的是CPU严重耗尽或大量swap：当节点负载过高时，CSSD进程可能长时间得不到调度，无法按时发出心跳，集群便认为节点死亡。这类问题的隐蔽之处在于，重启后负载下降，一切看起来正常，只有OSW的历史数据才能还原真相。同样的道理，LMS进程（Global Cache Service的Server进程）如果因为数据文件IO hang或bug而长时间阻塞，也可能通过reconfig机制引发节点重启。排查时应重点检查故障时刻的vmstat、top数据，看是否存在runq持续高于CPU核数、swap in/out活跃、CPU single user mode占比异常等情况。
数据库和集群软件自身的缺陷也是重要来源。比如特定版本CSSD、OHASD的已知bug，GRID打补丁不及时，或者第三方软件（如监控Agent、防病毒进程）误杀或挂起Oracle关键进程。Oracle MOS上大量已知问题都对应着特定的patch，遇到无明确外部诱因的驱逐时，核对GI和DB的PSU版本、检索已知bug是必做步骤。另外，内存管理参数配置不当，比如vm.min_free_kbytes设置过低导致内存耗尽时进程被OOM Killer杀掉，也可能间接造成驱逐。
# 从OSW归档中回溯故障时刻的负载 cd /osw/archive/vmstat # 关注 r 列(runq)、si/so(swap) 、cs 上下文切换 # 检查Oracle关键进程是否被OOM杀掉 dmesg | grep -i -E "kill|oom" grep -i "out of memory" /var/log/messages # 检查CSSD进程的调度延迟痕迹 grep -i " scheduling delay " $GRID_HOME/log/`hostname -s`/cssd/ocssd.log
最后需要提醒的是，每次驱逐发生后务必保留完整的故障现场：alert log、ocssd.log、OSW归档、主机messages日志，以及Automatic Diagnostic Repository下的驱逐相关trace文件。没有这些证据，后续的根因分析基本无从谈起。日常运维中建议部署OSW或exawatcher并保证归档周期覆盖数天，同时对私有网络做冗余和监控，这两项投入能显著降低驱逐问题的定位难度。
Oracle RAC节点驱逐OCR修改时间：2026-09-05 13:52:37