VIP绑定需验证OS层ip addr show输出，监听器必须在漂移后VIP上实际监听，SCAN高可用依赖SCAN Listener自动路由而非VIP漂移，CVU或网络资源异常会阻塞漂移。
确认VIP和SCAN VIP是否真绑到了网卡上
光看crsctl stat res -t显示online不等于vip真的可用。必须登录节点，用ip addr show查实际绑定情况。常见错误是vip出现在私网口（如eth1）或根本没出现——说明usr_ora_if配置错，或链路检测失败后被跳过绑定。
验证步骤：
- 运行
crs_stat -p ora.<nodename>.vip | grep USR_ORA_IF</nodename>，拿到接口名（比如eth0） - 执行
ip addr show eth0，确认输出里有inet <vip-address>/<mask></mask></vip-address> - 若VIP在
eth1或没出现，说明漂移“形同虚设”：IP地址虽被集群标记为接管，但OS层未生效，客户端ping不通
检查监听器是否在漂移后的VIP上真正监听
VIP漂移到node2，不代表node2的监听器就自动开始监听那个VIP。这是最常被忽略的一环：LISTENER_node2默认只监听自己的node2-vip和node2，不监听node1-vip——所以即使VIP ping得通，lsnrctl status也看不到该地址的端口监听，TCP连接直接被拒绝。
正确验证方式：
- 在VIP当前所在节点（比如node2）执行
lsnrctl status | grep -A 5 "Listening Endpoints" - 确认输出中包含
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip)(PORT=1521))) - 若没有，说明监听未注册，此时客户端连
node1-vip必失败；这不是VIP问题，而是监听配置或remote_listener参数没指向SCAN导致
模拟故障并观察SCAN Listener是否自动路由
SCAN的高可用不是靠VIP漂移，而是靠SCAN Listener做代理。验证重点不是“SCAN IP有没有飘”，而是“客户端连SCAN时，故障节点流量是否被自动绕开”。
操作建议：
- 停掉node1的数据库实例：
srvctl stop instance -i testdb1 -n node1 - 用
tnsping rac-scan确认DNS仍能解析（至少返回一个SCAN IP） - 在客户端执行
sqlplus /@rac-scan，成功后立刻查SELECT INSTANCE_NAME, HOST_NAME FROM V$INSTANCE; - 重复多次，观察是否始终连到node2；若某次连到node1且报错，说明SCAN Listener未及时注销该实例服务（检查
srvctl config scan_listener和各节点local_listener设置）
排查CVU或网络资源阻塞导致漂移卡住
有时VIP状态卡在INTERMEDIATE或FAILED OVER，crsctl stat res -t里VIP下面一堆依赖资源离线——很可能是ora.cvu或ora.<netname>.network</netname>没正常释放，阻塞了整个漂移流程。
快速定位：
- 执行
crsctl stat res -t | grep -E "(cvu|network)"，看是否有资源状态异常 - 查日志：
tail -20 $GRID_HOME/crs/log/<hostname>/racg/racgvip.log</hostname>，搜索IsIfAlive和failed - 若发现
ora.cvu状态异常且无法stop，可临时执行crsctl stop res ora.cvu -f再试VIP启动（注意：CVU健康检查6小时一次，临时停不影响集群运行）
