vip漂移成功不等于监听器自动监听，必须验证os层绑定、监听器端口注册、网络arp响应及客户端dns解析四层对齐。
不是VIP没飘成功，而是飘过去之后监听器根本没在那个地址上监听——客户端能ping通VIP，但lsnrctl status里压根看不到它，TCP连接直接被拒绝，自然卡在超时。
为什么VIP漂移后lsnrctl status不显示该地址
VIP只是个IP地址，它本身不带监听器。Oracle RAC中每个节点的监听器（如LISTENER_node1）默认只绑定自己的node1-vip和物理主机名，不会自动监听“飘过来”的node2-vip。哪怕VIP已出现在ip addr show输出里，只要监听器没注册该地址，端口就没人守着。
- 检查方式：在当前VIP所在节点执行
lsnrctl status | grep -A 5 "Listening Endpoints"，确认输出中含(HOST=node1-vip) - 常见误操作：手动改
listener.ora加静态地址——在11.2+ GI中无效，CRS根本不认这个文件里的TCP配置 - 正确路径：必须用
srvctl modify listener -s或通过endpoints_listener.ora由Clusterware统一管理
tnsnames.ora写VIP还是SCAN？超时根源在这儿
写两个VIP地址看似冗余，实则埋下超时隐患。客户端按顺序尝试，第一个VIP若已漂移到别处但监听未就绪，就会卡满SQLNET.INBOUND_CONNECT_TIMEOUT（默认60秒）才切下一个。
- 用SCAN则完全不同：
(ADDRESS=(PROTOCOL=TCP)(HOST=rac-scan)(PORT=1521))，DNS返回任意一个SCAN IP，由SCAN Listener做二次路由，故障节点流量自动绕开 - 前提条件：所有节点
remote_listener必须设为rac-scan:1521，且DNS必须轮询（不能写死/etc/hosts） - 验证方法：停掉一个实例后反复
sqlplus /@rac-scan，查V$INSTANCE，结果应始终落在存活节点
子网掩码不一致导致VIP“假飘”
VIP能出现在ip addr里，不代表它真能收包。如果OCR中记录的子网掩码、操作系统网卡配置（/etc/sysconfig/network-scripts/ifcfg-bond0）、以及srvctl modify nodeapps -A里给的掩码三者不一致，内核会静默拒绝ARP响应——客户端ping可能通（靠邻居缓存），但新连接必失败。
- 排查命令：
ip r | grep "dev.*[a-z]"确认VIP所属子网是否在本地直连路由表中 - 关键检查点：
crsctl stat res -p ora.<nodename>.vip | grep USR_ORA_IF</nodename>拿到接口名，再用ip -br a核对真实网卡名（别信eth0，可能是ens192） - 云环境特别注意：阿里云/腾讯云默认禁用辅助IP绑定，需单独开通“辅助私有IP”权限
最易被忽略的一点：VIP漂移是秒级的，但监听器注册、SCAN Listener服务发现、客户端DNS缓存刷新，这三者不同步——任何一环卡住，都会让“已飘”的VIP变成黑洞。不要只盯crsctl stat res -t的online状态，得逐层验证OS层绑定、监听器端口、网络层ARP、客户端解析四层事实是否全部对齐。
