南瑾i上周处理完一次凌晨的数据库切换，回到座位上我一直在想一个问题：为什么每次ADG切换完之后，最难的不是数据库本身的switchover，而是跟业务方一遍遍确认“现在应该连哪个IP”。如果业务连接串里写的是主库的物理IP，切换后这个IP对应的机器已经变成备库，应用自然全部失联；如果你让业务方同时配置两个IP做故障转移，很多老系统根本做不到。最终把问题解决干净的方案，就是给ADG环境单独规划一个VIP（虚拟IP），让应用永远只认这一个地址。这篇文章我重点讲Oracle ADG环境下的VIP高可用部署，完整过一遍网络规划、绑定脚本、监听器整合、主备切换联动，以及我在真实环境里踩过的坑。
这个场景适合谁？如果你正在做Oracle Data Guard的运维，或者你的ADG环境经常要手动切换、甚至已经配了Fast-Start Failover但发现切换后客户端不知道怎么连，那这篇文章应该能帮你省不少试错时间。哪怕你还没搭过ADG，先把连接层的思路理清楚，后面再倒回去看RAC和ADG的配合也会容易很多。
1. 为什么ADG高可用里非要多养一个VIP：主备切换的连接困境
1.1 先看清楚ADG环境长什么样
一个典型的ADG环境，两台数据库服务器，一台是Primary（主库），一台是Physical Standby（物理备库）通过Data Guard实时同步。ADG模式下备库可以以只读方式打开，平时还能承担一些报表查询，这一点和普通Data Guard有很大的体验差异。
两台服务器各自有自己的物理IP，比如：
| 机器 | 角色 | 物理IP |
|---|---|---|
| DB01 | Primary | 192.168.1.101 |
| DB02 | Physical Standby | 192.168.1.102 |
| VIP | 应用访问入口 | 192.168.1.200 |
这个VIP平时绑在DB01上，应用通过192.168.1.200连接数据库。一旦发生主备切换，VIP自动从DB01漂移到DB02，DB02变成新的Primary，应用连接串不用做任何修改，依旧连192.168.1.200就能访问到新主库。
听着很简单，但这个“自动漂移”包含了一层非常关键的设计思路：应用和数据库之间不应该绑定物理机器的IP，应该绑定一个“逻辑入口”。这个逻辑入口就是VIP。
1.2 没有VIP时，应用连接是怎么断的
没有VIP的情况下，业务方通常会有两种连法。
第一种，连接串写主库物理IP。比如应用配置里写死192.168.1.101。切换前没问题，切换后DB01降级为备库，数据库处于只读或者挂载状态，应用再往这个IP上写数据，轻则报错重则完全无法连接。DBA要做的事情就是通知业务方修改配置，把连接串改成新主库的192.168.1.102，然后重启应用。这个操作在计划内切换还能接受，最怕的是半夜故障，业务方没有人能马上改配置，恢复时间被拉得很长。
第二种，连接串里写两个物理IP做故障转移。Oracle客户端本身是支持多地址failover的，在tnsnames.ora里可以配两个ADDRESS，客户端会按顺序尝试。但如果应用用的是连接池，很多连接池在建立连接后会一直复用同一个物理连接，只有连接池本身发现连接断开并重试时，才会走到第二个地址。这里的变量太多：连接池是否配置了连接检测、检测间隔多久、failover模式是session还是select……任何一个环节不配合，就会出现“数据库已经切换好了，但应用迟迟连不上”的尴尬局面。
VIP方案解决的就是这个“入口漂移”问题。不管背后是哪台机器承担Primary，应用只认192.168.1.200这一个地址，入口不变，切换对应用层透明。严格来说，VIP并不能保证会话在切换过程中不断，真正的会话恢复还是需要应用侧重连，但它至少解决了“应用知道往哪连”的问题。
1.3 VIP在这里扮演的角色和边界
很多人会混淆VIP和其他Oracle高可用组件的关系。RAC里有SCAN IP和VIP，那是集群内部用来做实例负载均衡和故障转移的；ADG里讲的VIP是自己规划的虚拟地址，和RAC没有直接关系。
这里要明确边界：VIP只负责网络访问入口的漂移，它不负责数据库角色切换，也不负责任何数据同步。主备切换的决策和执行由Data Guard、DG Broker或者运维人员完成，VIP只是跟在Primary屁股后面的“影子”。切换发生在数据库层，漂移发生在网络层，两者必须通过脚本来联动。
这个边界想清楚了，后面做方案设计时就不会把逻辑搞混。我在早期刚接触ADG时，曾经想过用VIP的存活来做个数据库切换判断，后来想想就离谱：VIP在主库上，不代表数据库一定健康；反过来，VIP漂走了，也不代表原主库一定挂了。判断数据库角色，必须查数据库自身的状态，而不是通过网络地址的归属来判断。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. VIP方案最初的几个选择：网段、绑定方式和工具
2.1 网络规划：VIP放在哪个网段，会不会被DHCP抢走
VIP规划最容易被忽略的一个点，就是地址来源。这个VIP必须是一个固定的、没有被占用的、不会被DHCP自动分配的IP。
实操中我一般会做三件事：
- 在交换机或者防火墙侧把VIP地址加入静态ARP白名单，确保不会因为其他设备的MAC广播导致地址冲突；
- 检查DHCP地址池，确认VIP不在自动分配范围内；
- 在资产管理或者IP登记表里注明这个IP是ADG VIP，避免后续其他项目误申请。
VIP和数据库物理IP尽量放在同一个网段。原因是VIP漂移本身是二层网络行为，同网段内通过ARP广播就可以快速切换路由指向。跨网段的VIP漂移需要三层路由协议配合，复杂度会上升一个量级，不是DBA自己写个脚本就能搞定的。我在多个环境里都验证过，同网段内VIP漂移的时间可以达到秒级，跨网段则需要依赖VLAN间路由的收敛，通常不建议这么做。
另外，VIP不能和任何物理机的实际IP冲突。有些生产环境会直接把两台机器的某一个备用IP地址规划为VIP，但后来另一台机器上线时又把这个地址配上，造成地址冲突，这种事故并不少见。规划完成后，至少要用ping和arping测试一下这