VIP ONLINE仅表示racgvip进程启动成功，不验证网卡真实收发能力；根本原因是链路活性检测失败——ping网关无RX包增量即强制漂移，即使物理链路正常。
vip漂移不是故障本身，而是集群对底层网络异常的响应结果；真正要查的是网卡链路是否被误判为失效。
为什么crsctl stat res -t显示VIP ONLINE，但实际已漂移？
因为VIP资源状态只反映Clusterware是否成功启动了racgvip进程，不验证该进程绑定的网卡是否真能收发包。常见现象是：ora.node1.vip在node2上显示ONLINE INTERMEDIATE FAILEDOVER，但ifconfig里根本看不到node1-vip这个地址——它压根没绑上去。
- 根本原因常是
racgvip启动时执行的链路活性检测失败：它会尝试用$PING -S $tmpIP $DEFAULTGW探测默认网关，若连续CHECK_TIMES次（默认3次）无RX包增量，则强制将VIP标记为“不可用”并触发漂移 - 即使物理网卡
eth0链路灯常亮、ethtool eth0显示Link detected: yes，只要网关不通或ARP未响应，racgvip就认为接口死亡 - 检查路径：
$GRID_HOME/crs/log/中搜索/racg/racgvip.log IsIfAlive: RX packets checked if=和failed关键字
如何确认VIP绑定的网卡是否真实可用？
不能只看oifcfg getif输出，必须验证VIP实际使用的网卡是否能完成三层通信。Oracle要求VIP与Public IP在同一子网、同一物理接口，但配置错误会导致VIP被绑到错误网卡甚至私网口。
- 查VIP实际绑定位置：
ip addr show—— 找到inet所在网卡，比如/ eth0；若出现在eth1（私网口），说明USR_ORA_IF属性配置错误 - 查VIP依赖的网卡接口名：
crs_stat -p ora.—— 输出类似.vip | grep USR_ORA_IF USR_ORA_IF=eth0，必须与ip addr结果一致 - 手动模拟
racgvip检测逻辑：ping -c 3 -I eth0，若丢包或超时，就是VIP漂移的直接诱因
FAIL_WHEN_DEFAULTGW_NO_FOUND=0真的能禁用网关检测吗？
不能完全禁用，只能绕过“无默认网关”这一特定判断分支；只要网关存在，racgvip仍会执行RX包检测。修改该参数后漂移依旧，说明问题出在网关连通性本身，而非参数开关。
- 该参数仅影响
if [ -n "$DEFAULTGW" ]为假时的行为，即系统没配default route的情况；一旦route -n | grep '^0.0.0.0'有输出，后续所有检测照常执行 - 真正有效的临时规避方式是确保网关可达：检查交换机ACL、VLAN配置、防火墙策略，尤其注意是否限制了ICMP或源IP伪装
- 长期方案是调整网络架构：避免将RAC公网网关设在单点设备上；若必须使用，需确认网关设备自身高可用且ARP表稳定
CVU健康检查阻塞VIP漂移怎么快速定位？
当ora.net1.network离线后，VIP无法漂移的典型表现是：crsctl stat res -t中VIP状态卡在OFFLINE或INTERMEDIATE，且crsctl debug log res "ora.日志末尾停在waiting for dependency。
- 关键线索：
crsctl stat res -d ora.cvu—— 若显示STATE_DETAILS为Running on nodeX，而nodeX恰好是公网故障节点，则CVU正在阻塞依赖链释放 - 验证方法：
ps -ef | grep cvu看是否有cvuqdisk或cvu_进程残留；srvctl status cvu若返回running但crsctl check crs报错，基本可确认 - 应急操作（仅限维护窗口）：
srvctl stop cvu -f→crsctl start res ora.；事后务必.vip -n srvctl enable cvu
最易被忽略的一点：VIP漂移后，新节点上lsnrctl status查不到对应VIP的监听端口，不是配置遗漏，而是Oracle设计如此——它依赖SCAN Listener做连接路由，而不是让每个节点监听所有VIP。强行改listener.ora加HOST=xxx-vip反而破坏集群自治能力。
