VIP漂移失败主因是监听器未在新节点注册，非VIP未移动；需验证VIP是否真绑定网卡（ip addr show）、监听是否监听该VIP（lsnrctl status + ss）、DNS/hosts合规性及CVU等依赖资源状态。
VIP漂移失败，90%不是VIP本身没动，而是监听器没在新节点上注册监听——所以客户端连不通，不是VIP没飘过去，是监听压根没起来。
确认VIP是否真被当前节点持有
别信 crsctl stat res -t 显示 ONLINE 就完事。它只说明 CRS 认为资源该在线，不代表 IP 已绑定到网卡。
- 先用
srvctl config scan和srvctl config nodeapps拿到所有 VIP 地址（比如192.168.10.51） - 登录疑似接管节点，执行
ip addr show，搜索该 VIP 是否作为/32secondary 地址出现在公网接口（如ens33）上 - 若没出现，检查
crsctl stat res ora.node1.vip -p | grep USR_ORA_IF输出的接口名，再比对oifcfg getif -global是否一致；不一致就导致 CRS 拒绝绑定 - 若 VIP 出现在私网口（如
eth1），说明USR_ORA_IF配错了，或链路检测失败后被跳过
验证监听器是否在VIP所在节点真正监听
VIP 飘过去了，但 LISTENER_node1 不会自动跨节点启动。新节点上只有自己的监听器，默认不监听旧节点的 VIP。
- 在 VIP 当前所在节点（比如 node2）执行
lsnrctl status LISTENER_node2 - 重点看
Listening Endpoints Summary段：必须含类似(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip)(PORT=1521)))的条目 - 若没有，说明监听未注册该 VIP —— 这不是 VIP 问题，是
remote_listener参数没设对，或local_listener指向错误 - 用
ss -tuln src <node1-vip>:1521</node1-vip>确认端口是否真被监听；lsof -i @<node1-vip>:1521</node1-vip>更准
检查DNS与hosts对SCAN和VIP的影响
Oracle 19c 对 DNS 解析极其敏感，哪怕 /etc/hosts 里只写了一行 SCAN 条目，也会让 SCAN Listener 启动失败，进而影响 VIP 监听注册逻辑。
- 立刻清空
/etc/hosts中所有 SCAN 和 VIP 相关行——哪怕写三行，19c 也只认作单解析源 - 执行
nslookup rac-scan.example.com，输出必须严格三行Address:，且全部属于 SCAN 网段；返回 CNAME 或单 IP 都会导致静默失败 - 查
dig +short _scan._tcp.rac-scan.example.com SRV，确保返回端口是1521，且服务名正确 - 注意：
srvctl status scan_listener显示 ONLINE ≠ SCAN Listener 真正在监听；必须配合lsnrctl status LISTENER_SCAN1和ss双重验证
排查CVU或网络资源阻塞漂移流程
有时 VIP 卡在 INTERMEDIATE 或反复 FAILED OVER，不是 VIP 配置问题，而是依赖资源没释放干净。
- 运行
crsctl stat res -t | grep -E "(cvu|network)"，看ora.cvu、ora.<netname>.network</netname>是否都 ONLINE - 若某网络资源 OFFLINE，VIP 漂移会被阻塞；此时不能硬起 VIP，得先恢复底层网络资源
- 查
$GRID_HOME/log/`hostname`/agent/oraagent_grid.log，搜Failed to bind address或TNS-12560，常指向 OCR 与 OS 网络状态脱节 - 别忽略私网状态：
ping -I <private_if><other_node_private_ip></other_node_private_ip></private_if>，私网不通会直接触发节点驱逐，VIP 漂移变成“事后补救”而非“快速切换”
真正难搞的点往往藏在“监听器没注册 VIP”这个环节：它不报错、不宕机、crsctl 看着全绿，但客户端就是连不上。这时候必须跳出 VIP 层面，直奔监听器日志和 ss 输出——因为 Oracle RAC 的高可用，从来不是靠 IP 漂移本身，而是靠监听器能否在漂移后秒级承接连接请求。
