VIP漂移失败主因是监听器未在新节点注册VIP，而非网络问题；须分别验证VIP是否绑定网卡（ip addr）和监听器是否监听该VIP（lsnrctl status），并确保remote_listener指向SCAN。
VIP漂移失败，90%不是VIP没动，而是监听器压根没在新节点上注册——客户端连不通的根源在这里，不是网络或IP配置问题。
确认VIP是否真绑定到网卡（别信crsctl stat res -t）
CRS显示ONLINE只代表资源状态正常，不代表IP已实际绑定到操作系统网卡。必须登录疑似接管节点，用底层命令验证：
- 先查VIP地址：
srvctl config nodeapps或srvctl config scan拿到所有VIP（如192.168.10.51） - 再查绑定接口：
crsctl stat res ora.node1.vip -p | grep USR_ORA_IF，得到接口名（如ens33） - 最后确认OS层生效：
ip addr show ens33 | grep 192.168.10.51，输出应含inet 192.168.10.51/32 - 若VIP出现在私网口（如
eth1）、或根本没出现，说明USR_ORA_IF配错，或链路检测失败后被跳过绑定
验证监听器是否在漂移后VIP上真正监听（关键！）
VIP飘到node2，不等于LISTENER_node2会自动监听node1-vip。默认它只监听自己节点的VIP和主机名。
- 在VIP当前所在节点执行：
lsnrctl status LISTENER_node2 - 重点看
Listening Endpoints Summary段：必须有类似(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip)(PORT=1521)))的条目 - 若没有，立刻检查：
show parameter remote_listener—— 它必须指向SCAN地址（如rac-scan.example.com:1521），而非空或本节点VIP - 同时确认
local_listener指向正确（通常是(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<node-vip>)(PORT=1521)))</node-vip>） - 用
ss -tuln | grep :1521或lsof -i @<node1-vip>:1521</node1-vip>双重确认端口是否真被监听
排查DNS与/etc/hosts对SCAN和VIP的干扰（Oracle 12c尤其敏感）
Oracle 12c对DNS解析异常严格：哪怕/etc/hosts里只写了一行SCAN条目，SCAN Listener就可能静默启动失败，进而阻断VIP监听注册链路。
- 立即清空
/etc/hosts中所有含SCAN、VIP、节点名的行（只留localhost） - 执行
nslookup rac-scan.example.com：输出必须严格三行Address:，且全部属于SCAN子网；返回CNAME、单IP或超时都算失败 - 执行
dig +short _scan._tcp.rac-scan.example.com SRV：确保返回端口是1521，服务名格式为rac-scan.example.com.（末尾带点） -
srvctl status scan_listener显示ONLINE≠ 真监听 —— 必须配合lsnrctl status LISTENER_SCAN1和ss验证
绕过VIP依赖，改用SCAN实现透明故障转移（推荐生产方案）
硬解VIP漂移问题成本高、易反复；而SCAN天然规避了VIP监听注册难题，客户端连接完全不受节点宕机影响。
- 客户端
tnsnames.ora中弃用双VIP写法，改用SCAN：(ADDRESS=(PROTOCOL=TCP)(HOST=rac-scan.example.com)(PORT=1521)) - 确保所有节点
remote_listener统一设为SCAN地址，且DNS轮询启用（禁用/etc/hosts静态映射） - 验证方式：停掉一个实例
srvctl stop instance -i racdb1 -n node1，然后反复sqlplus /@rac-scan，SELECT INSTANCE_NAME FROM V$INSTANCE应始终返回健康节点 - 注意：SCAN VIP本身不漂移，它的高可用靠SCAN Listener自动路由，不是靠VIP机制
最常被忽略的点：监听器是否监听VIP，和VIP是否绑定网卡，是两个独立动作，必须分别验证；而remote_listener指向错误，会让整个注册逻辑失效，且日志里往往无明显报错。
