VIP是Oracle RAC中由Clusterware动态管理的虚拟IP，不绑定网卡但作为客户端唯一推荐连接入口；漂移后监听器不自动注册导致连接失败，应优先使用SCAN实现透明故障转移。
什么是VIP？它不是网卡上配的IP，但比物理IP还关键
vip（virtual ip）是oracle clusterware为每个rac节点自动分配的一个“服务出口地址”，它不绑定在操作系统网卡配置里（ifconfig看不到它被永久启用），而是在集群启动时由ohasd和ora.<nodename>.vip</nodename>资源动态绑定到某块公网网卡上。客户端连数据库用的不是节点物理ip，而是这个vip——这才是oracle官方唯一推荐的连接入口。
- 客户端tnsnames.ora中写的是
HOST=rac1-vip，不是HOST=rac1（即物理IP） - VIP必须和Public IP在同一子网、同一网卡接口，否则Clusterware拒绝启动该资源
- 一旦节点宕机或CRS异常终止，VIP会在2–5秒内自动漂移到其他健康节点，但监听器不会自动注册到新节点——这是最常被忽略的致命点
为什么VIP能“秒级”响应故障，但应用仍连不上？
能ping通VIP ≠ 能连上数据库。VIP漂移后，你看到ping rac1-vip成功，只是IP地址被另一个节点接管了；但那个节点上并没有为rac1-vip启动对应的监听器实例（lsnrctl status查不到该地址的监听端口），所以TCP连接会直接被拒绝或超时。
- 漂移后，原实例的监听器（
LISTENER_<nodename></nodename>）不会跨节点启动，它只随实例生命周期存在 - 新节点上只有自己的监听器（比如
LISTENER_rac2），默认只监听rac2-vip和rac2，不监听rac1-vip - 解决方案不是手动改监听配置，而是靠Oracle的
SCAN Listener+srvctl modify listener -s机制做统一代理，或者确保客户端使用SCAN而非单个VIP
tnsnames.ora里该写VIP还是SCAN？真实场景怎么选
写SCAN更健壮，写VIP更可控——但多数人误以为“VIP更底层所以更可靠”，其实恰恰相反。
- 如果tnsnames里只列两个VIP：
(ADDRESS=(PROTOCOL=TCP)(HOST=rac1-vip)(PORT=1521))和(ADDRESS=(PROTOCOL=TCP)(HOST=rac2-vip)(PORT=1521))
→ 节点1宕机后，客户端首次连接会尝试rac1-vip，等TCP超时（默认约60秒）才切到rac2-vip，用户感知明显卡顿 - 如果用SCAN：
(ADDRESS=(PROTOCOL=TCP)(HOST=rac-scan)(PORT=1521))
→ DNS返回三个SCAN IP之一，SCAN Listener自动将连接路由到负载最低的活跃实例，VIP漂移对客户端完全透明 - 注意：SCAN必须配合DNS轮询（不能写死hosts），且所有节点的
remote_listener参数必须指向SCAN地址
检查VIP状态和排查漂移失败，这几个命令不能少
别只看crsctl stat res -t显示ONLINE就认为没问题——VIP资源在线，不代表它真绑定了、没被ARP缓存污染、没被防火墙拦截。
- 查VIP当前归属：
crsctl stat res ora.rac1.vip -p | grep USR_ORA_VIP - 看是否真的在网卡上生效：
ip addr show | grep 192.168.59.162（替换成你的VIP） - 检查ARP表是否陈旧：
arp -n | grep 192.168.59.162，若MAC仍是宕机节点，清掉：arp -d 192.168.59.162 - 验证监听注册：
lsnrctl status LISTENER_SCAN1，确认输出里有Service "rac" has 2 instance(s)
VIP机制本身很稳定，真正出问题的90%都卡在外部依赖：DNS缓存、交换机ARP老化、客户端JDBC驱动未启用oracle.jdbc.replay.enable=true、或者运维手动删了/etc/hosts里的VIP条目却忘了同步DNS。
