首先，形成一项核心判断：在 Oracle RAC 环境中，VIP 漂移无法完成，绝大多数情况并非“漂移失败”——而是 VIP 根本就未能启动，甚至从未尝试过漂移。如何验证？只需查看 ora.nodeX.vip 资源的状态，如果显示为 OFFLINE 或 INTERMEDIATE，说明它根本没有绑定到网卡上。此时，无需深究漂移算法或心跳延迟，而应优先梳理 VIP 的启动链路。
ora.net1.network 离线直接阻止 VIP 启动
VIP 资源高度依赖于网络资源 ora.net1.network（也可能存在其他类似命名）。只要这个上游资源处于离线状态，VIP 进程就不会被拉起。因此，遇到问题时，不要急于钻牛角尖，先确认上游资源是否在线：
- 执行
crsctl stat res -t | grep network，检查ora.net1.network的状态是否为ONLINE。 - 如果显示
OFFLINE，应立即检查当前节点是否配置了默认网关：route -n | grep '^0.0.0.0'。若无输出，补充默认网关；若有输出，验证连通性：ping -I。 - 常见陷阱：多网卡环境中容易遗漏网关配置，或网关位于另一个子网但未添加静态路由，这类问题最为隐蔽。
- 还有一种更刁钻的情况：如果
ora.cvu资源仍处于 online 状态且依赖公网，CRSD 可能会卡在“等待所有依赖资源停止”的阶段，导致ora.net1.network始终无法重启。解决方案：先执行srvctl stop cvu，再执行crsctl start res ora.net1.network。
USR_ORA_IF 指向私网网卡导致 VIP 绑定错位
VIP 必须绑定在公网网卡上，这是基本原则。但若 USR_ORA_IF 属性被误设为私网网口名称（例如 eth1），则 racgvip 脚本会将地址绑定到私网口上——现象为 ip addr show 中 VIP 出现在 eth1 下，但客户端无法访问。排查方法如下：
- 查看当前配置：
crs_stat -p ora.node1.vip | grep USR_ORA_IF，输出类似USR_ORA_IF=eth0|eth1。 - 必须删除所有非公网网卡名，仅保留一个，例如
USR_ORA_IF=eth0。 - 修改方式：导出配置
crs_stat -p ora.node1.vip > /tmp/vip.cap→ 编辑文件 →crsctl replace resource ora.node1.vip -f -p /tmp/vip.cap。 - 验证：重启 VIP 后，
ip addr show中的 VIP 必须出现在您指定的公网接口下，并且该接口的链路状态必须正常（ethtool eth0显示Link detected: yes）。
交换机端口安全策略拦截新节点 MAC 地址
VIP 漂移后，使用的是目标节点网卡的 MAC 地址。如果交换机启用了端口安全（port security），但新节点的 MAC 未被放行，则 ARP 响应会被静默丢弃——客户端 ping 不通、TCP 连接超时，但表面上一切似乎正常。这是最难定位的问题。排查步骤：
- 在目标节点执行
ifconfig eth0，记录ether后面的 MAC 地址。 - 登录交换机，查看该物理端口的 MAC 表：
show mac address-table interface Gi1/0/5（替换为实际端口），确认新节点的 MAC 是否已存在。 - 检查端口安全状态：
show port-security interface Gi1/0/5。如果Security Violation Count大于 0，或Security Action为shutdown，则基本确定是此问题。 - 临时解决方案：在交换机上执行
no switchport port-security。长期方案：将 RAC 所有节点的公网网卡 MAC 添加到交换机白名单中。
网卡名不一致导致 srvctl 直接拒绝启动 VIP
Clusterware 对公网网卡设备名的要求是“字面完全一致”。即使仅存在 enp0s3 与 ens192 这样的细微差异，srvctl start vip 也会直接报错 invalid interface "ens192" 并拒绝执行。要验证这一点：
- 逐节点执行
$GRID_HOME/bin/oifcfg getif，对比输出是否完全一致。 - 真实的接口名以
ip -br a或ls /sys/class/net/为准，不要轻信旧文档或 ifconfig 的别名。 - 在 Linux 环境下，统一命名依赖
/etc/udev/rules.d/70-persistent-net.rules绑定 MAC 与名称；AIX 下需核对/etc/path_to_inst中的驱动实例顺序。 - 特别提醒：虚拟化平台（VMware/KVM）和云环境（AWS/阿里云）常因驱动不同导致网卡名天然不一致，必须手动对齐，否则迟早会踩坑。
实际上，真正令人头疼的往往在于底层细节：您以为 VIP 已经漂移成功，但它连操作系统网卡都未绑定；您以为交换机配置无误，但端口安全正在静默丢弃数据包；您以为网关可以 ping 通，但 racgvip 检查的是 RX 包增量，而非 ICMP 回包本身。逐一厘清这些底层细节，VIP 漂移才能真正“动”起来。
