vip未漂移主因是集群未识别故障或漂移后未生效；需用crsctl stat res -t查状态、ip addr show确认os层绑定、srvctl status scan验证scan监听、nslookup检查dns轮询，并确保启用ping target机制。
VIP没漂移，90%不是RAC坏了，而是集群没把它当故障处理，或者漂了但根本没生效。
crsctl status res -t 显示 VIP ONLINE，但实际没漂过去
状态显示 ONLINE 只代表 CRS 资源注册成功，不等于 OS 层真绑定了 IP。必须登录存活节点执行 ip addr show <public-if></public-if>（比如 ip addr show eth0），确认输出里真有那条 inet <vip-address>/<mask></mask></vip-address>。常见坑是 VIP 被绑到私网口（如 eth1）或压根没出现——说明 USR_ORA_IF 配置错，或链路检测失败后跳过了绑定步骤。
- 查接口名：
crs_stat -p ora.<nodename>.vip | grep USR_ORA_IF</nodename> - 查是否真绑定：
ip addr show <interface></interface>，不是ifconfig（它不显示动态添加的 VIP） - 若 VIP 在错误网卡上，需用
srvctl modify nodeapps -n <node> -A <vip>/<netmask>/<ifname></ifname></netmask></vip></node>修正
SCAN 监听没接管，导致新连接进不来
节点宕机后，ora.LISTENER_SCAN1.lsnr 必须由存活节点继续提供服务。如果它在 crsctl status res -t 中是 OFFLINE 或 INTERMEDIATE，手工跑 lsnrctl start 没用——那是本地监听，不是 SCAN 监听。
- 确认 SCAN 监听状态：
srvctl status scan和srvctl status scan_listener - 检查 DNS 解析：
nslookup <scan_name></scan_name>，返回的 IP 列表中不能含宕机节点的 VIP - 若 SCAN 监听 STOPPED，先查
$GRID_HOME/log/<node>/agent//oraagent_grid.log</node>是否有Failed to bind或 OCR 错误
客户端根本没连 VIP，或者连了但 DNS 没轮询
很多“连 VIP”的配置其实是假的：tnsnames.ora 里写的是某个节点物理 IP，或 DNS 把 SCAN 名固定解析到一个 IP 上，导致负载始终打到单点。
- 查应用连接串是否含
(HOST=<scan_name>)</scan_name>，不是rac1-vip或rac1 - 在数据库端查
v$session，过滤machine或client_info，看来源 IP 是否还来自宕机节点 - 反复执行
tnsping <scan_alias></scan_alias>，观察返回的 IP 是否轮换；若始终一样，说明 DNS 没开 round-robin 或 TTL 太大（建议 ≤ 60 秒）
网络心跳没超时，CSSD 根本不认为节点挂了
ifconfig down 公网网卡不会触发 VIP 漂移，因为 CSSD 只检查网卡 UP 状态，不验证外网连通性。真实断网（拔线、交换机 down）才可能触发，但虚拟机环境常收不到 carrier down 通知。
- 确认是否启用 ping target：
srvctl config network -k 1，输出含Ping Targets才有效 - 没启用时，即使公网全不通，
crsctl check cluster仍返回 SUCCESS，ocssd.log也看不到missed heartbeat - 安全模拟故障应改用 iptables 丢 UDP 心跳包：
iptables -I INPUT -p udp --dport 12345 -s <other-node-ip> -j DROP</other-node-ip>
最麻烦的不是 VIP 没动，而是它动了但监听没注册、DNS 没更新、客户端连的还是旧地址——这些环节任何一个断掉，都会让“自动切换”变成“看起来自动，其实卡死”。
