vip不漂移是因为ifconfig down属管理操作，clusterware标记为admin_down并跳过心跳检测；真实断网需保持网卡up但丢udp 12345心跳包或启用ping target探测。
为什么ifconfig down网卡后VIP纹丝不动
这不是VIP失效，而是Clusterware根本没把它当故障——ifconfig down是管理操作，不是网络中断。集群看到的是“网卡被主动关闭”，状态标记为ADMIN_DOWN，直接跳过心跳检测流程，自然不触发驱逐或VIP漂移。
- 真实断网必须让网卡保持
UP但收不到包：比如拔物理线缆、在交换机侧shutdown端口、或用iptables -A OUTPUT -d <other_node_ip> -p udp --dport 12345 -j DROP</other_node_ip>丢心跳UDP包 - 虚拟机里拔vNIC线往往无效：VMware/KVM宿主机不通知客户机链路状态变化，
ethtool eth0仍显示Link detected: yes，RAC判定“一切正常” - 检查当前网卡是否还在心跳路径：
oifcfg getif输出里必须包含你配置的public网卡名；若已消失，说明已被Clusterware剔除，后续任何该接口上的操作都不再参与故障判定
crsctl check cluster返回SUCCESS但VIP就是不漂移
这说明集群健康，但故障条件未满足——最常见原因是misscount设得太大，或者ping target没启用。
-
misscount默认30秒（11gR2+），表示连续丢失misscount次心跳才判节点死亡；若你只断网20秒，而misscount=60，CSSD会安静等满60秒才行动 - 虚拟化环境建议设45–60，但绝不能盲目堆高；超过90秒基本失去快速响应意义
- 必须所有节点
misscount值一致，否则集群起不来；修改后需crsctl stop crs && crsctl start crs全量重启 - 查是否启用
ping target：srvctl config network -k 1，输出里要有Ping Targets字段；没启用时，即使拔了线、客户端连不上VIP，crsctl check cluster也永远返回SUCCESS
VIP漂移了但客户端还是连不上
能ping通VIP ≠ 能连上数据库。VIP只是IP地址漂移，监听器不会自动注册到新节点。
- 原节点宕机后，
LISTENER_rac1随实例终止，新节点rac2上只有LISTENER_rac2，默认只监听rac2-vip和rac2，不监听rac1-vip -
lsnrctl status在rac2上查不到rac1-vip的监听端口，TCP连接会被直接拒绝（不是超时） - 别手动改
listener.ora——Clusterware管理的监听器不允许硬编码VIP；正确做法是确保客户端用SCAN连接，由SCAN Listener统一代理路由 - 检查
remote_listener参数是否指向rac-scan，且DNS能轮询解析出至少一个SCAN IP
网卡名或子网配置错导致VIP压根起不来
VIP资源启动失败，根本不会进入漂移逻辑。常见静默失败点就两个：网卡名不匹配、子网不可达。
- 用
ip -br a确认真实网卡名（如ens192），别信旧文档写的eth0；云平台/容器环境更易出错，同一镜像在不同平台接口名可能完全不同 - VIP必须落在某块网卡的直连子网内：
ip r | grep "dev.*[a-z]"看路由表，确认VIP地址属于其中一条xx.xx.xx.xx/yy dev ens192 proto kernel范围 - 用了VLAN子接口（如
ens192.100）？VIP必须属于该子接口子网，不能写在物理口主网段 - 云厂商（阿里云、腾讯云）常禁用辅助IP绑定，即使路由表显示可达，底层也会拦截——得查文档是否支持“辅助私有IP”或“多IP绑定”
ifconfig down或拔线靠谱得多。
