确认是否被CSSD驱逐而非系统崩溃：先查ocssd.log中“node eviction initiated”或“reboot advisory”时间是否早于系统重启记录，再结合crsctl stat res -t资源全OFFLINE与ps检查ohasd/cssd进程状态综合判断。
oracle 12c rac节点频繁重启，基本就是被cssd驱逐（eviction）了，不是系统级宕机，而是集群主动踢出——查ocssd.log里有没有node eviction initiated或reboot advisory就能确认。别急着调misscount，90%的案例根源不在参数，而在底层连通性或资源争用。
怎么快速确认是不是被驱逐而非系统崩溃
先看日志时间线和进程状态，别被crsctl check cluster的“online”误导：
-
crsctl check cluster -all显示某节点“ONLINE”，但crsctl stat res -t里所有资源都是OFFLINE→ 典型“已注册未加入通信环”，说明CSSD没完成心跳协商，节点卡在中间态 - 查
$GRID_HOME/log/<hostname>/cssd/ocssd.log，搜索evicting node、node eviction initiated或reboot advisory；若出现，且时间点早于系统dmesg或/var/log/messages里的重启记录，基本可断定是集群驱逐 - 检查
ps -ef | grep ohasd和ps -ef | grep cssd：如果ohasd没进程，但crsctl stop crs -f又报CRS-4640: Oracle High Availability Services is already active→ 说明进程假死，本地元数据残留严重
为什么改了misscount还是被驱逐
调大misscount只是延长容忍窗口，不解决根本问题。真正导致驱逐的，往往是以下三类未暴露的异常：
-
voting disk所在ASM磁盘组IO延迟高：iostat -x 1中%util > 95或await > 50ms→ 磁盘心跳超时，disktimeout再大也救不了 - 私网实际不通但
ping能通：比如NIC offload开启（ethtool -K <priv_nic> gro on）导致TCP重传异常，必须用traceroute -n <private_ip>验证路径稳定性 - HAIP没起来：
ip a | grep 169.254无输出 →ora.cluster_interconnect.haip资源起不来，网络心跳直接失效；此时crsctl start res ora.cluster_interconnect.haip会报错
清理本地残留元数据的关键动作
节点被驱逐后强行crsctl start crs大概率失败，必须彻底清空本地状态：
- 强制停服务：
crsctl stop crs -f（不加-f会卡住） - 删socket文件：
rm -f /var/tmp/.oracle/NP*（否则ohasd无法绑定端口） - 检查
/etc/oracle/olr.loc是否指向有效路径，比如olrconfig_loc=/u01/app/12.1.0/grid/cdata/<hostname>；若权限是root:root或路径不存在，ohasd静默失败 - 执行
roothas.pl -deconfig -force：只清本地HAS配置，不影响其他节点，是重装前必须步骤
最容易被忽略的硬件与OS层问题
很多团队查完网络、存储、参数就放弃，其实驱逐常由更底层问题触发：
- 内存不足导致
oprocd/cssdmonitor调度失败：free -h看可用内存，dmesg | tail查OOM killer是否杀过进程；vm.swappiness设太高也会让内核疯狂swap - 时间不同步引发CTSS异常：即使NTP服务在跑，
ntpq -p显示offset > 1s，或ctssd日志里有clock drift警告，都可能间接导致CSSD误判 - 私网网卡驱动或固件bug：尤其在虚拟化环境或跨机架链路中，
ethtool <priv_nic>查link detected是否稳定，smartctl -a /dev/sdX排除磁盘底层故障
驱逐不是孤立事件，它永远是某个环节持续劣化的结果。查日志要顺着时间线倒推，从ocssd.log里的第一个告警开始，而不是从重启那一刻切入。网络和存储层的问题，往往在CSSD日志里只留下一句missed heartbeat，背后可能是光衰、offload、IO队列深度或大页配置错误——这些细节，才是决定能否真正止血的关键。
