节点被驱逐是集群为保障数据安全实施的主动隔离，根本原因在于心跳通信中断或ocr/voting disk访问异常；需通过crsctl check crs、ocssd.log日志、olsnodes状态及私网连通性等综合诊断底层故障源。
节点被驱逐不是故障本身，而是集群为保数据安全做出的主动隔离动作。真正要修的，是触发驱逐的底层原因——通常是心跳通信中断或OCR/Voting Disk访问异常。
确认驱逐是否已发生且节点已重启
先看现象再动手。驱逐后节点通常会强制重启，但有时卡在“半死”状态，导致后续诊断误判。
- 登录疑似被驱逐节点，执行
crsctl check crs：若返回CRS-4639: Could not contact Oracle High Availability Services，说明 CRS 进程已退出，大概率已被驱逐 - 查
$GRID_HOME/log/<hostname>/cssd/ocssd.log</hostname>，搜索evicted或missed heartbeat，确认驱逐时间点和直接原因（如 “missed 50% of heartbeats”） - 对比其他节点的
olsnodes -s -t输出：被驱逐节点状态会变成Inactive或直接消失，而非Active
检查网络心跳与私网连通性
Oracle 11g RAC 默认依赖私有网络（Private Interconnect）传递 CSS 心跳。哪怕公网上一切正常，私网不通照样驱逐。
- 用
ping和traceroute测试私网 IP（非 VIP、非 SCAN）互通性，例如：ping rac1-priv、ping rac2-priv - 检查
/etc/hosts中私网条目是否一致：所有节点必须用相同主机名解析私网地址，不能混用 DNS 或缺失条目 - 运行
ifconfig确认私网网卡（如eth1）UP 且有正确 IP；检查ethtool是否显示 link down 或 error 计数飙升 - 临时关闭防火墙验证：
service iptables stop（仅测试用），若驱逐停止，则需开放 UDP 12366（CSSD 心跳端口）及 TCP 通信端口
验证 Voting Disk 与 OCR 可访问性
磁盘心跳（Voting Disk）失效会导致仲裁失败，进而触发驱逐。OCR 损坏则让集群“失忆”，无法协调资源状态。
- 在所有存活节点执行
crsctl query css votedisk，确认输出中 Voting Disk 状态为ONLINE，且路径可被所有节点读写（如 ASM 磁盘组+OCR必须 mount 成功） - 运行
ocrcheck：若报错PROT-602: Failed to retrieve data from the cluster registry，说明 OCR 访问异常，需进一步检查 ASM 实例状态和磁盘组权限 - 查看
$GRID_HOME/log/<hostname>/crsd/crsd.log</hostname>，搜索voting disk或OCR相关错误，常见如ORA-15032（ASM 未启动）、ORA-15066（磁盘离线） - 注意：Voting Disk 必须是奇数个（通常 3 个），且至少 N/2+1 个在线才能维持集群运转；少于该数将强制驱逐少数节点
清理残留 IPC 资源后再重启 CRS
节点异常终止后，共享内存段（shm）和信号量（sem）可能残留，导致新实例启动时分配失败，表现为 ORA-27154 或 PMON terminating due to error 481 —— 这类错误常被误认为网络问题，实则卡在 OS 层。
- 确保目标节点无任何 CRS 进程在跑：
ps -ef | grep -E "(crs|css|evm|ohasd)"应为空 - 以 root 执行
crsctl stop crs -f强制停掉所有集群服务 - 清理 oracle 用户拥有的 IPC 资源：
ipcs -m | awk '$5 == "oracle" {print $2}' | xargs -I {} ipcrm -m {}ipcs -s | awk '$5 == "oracle" {print $2}' | xargs -I {} ipcrm -s {} - 执行
ipcs -m -s确认输出为空，再运行crsctl start crs
最易被忽略的是私网配置一致性——哪怕只有一台节点的 /etc/hosts 私网条目多了一个空格，或网卡 MTU 设置不一致，都可能造成心跳包丢包率缓慢上升，最终越过驱逐阈值。排查时别只盯着日志里的“evicted”，先盯死私网链路的每一层。
