VIP资源状态为OFFLINE或INTERMEDIATE说明未成功绑定，主因是交换机MAC绑定限制或USR_ORA_IF配置错误导致绑定到私网网卡。
crsctl stat res -t 显示 ora.nodeX.vip 状态为 OFFLINE 或 INTERMEDIATE
这说明 vip 资源根本没起来，不是“漂移失败”，而是压根没完成绑定。常见诱因是网口物理层不通或交换机侧限制——比如交换机端口启用了 mac 地址绑定（port security），而 vip 漂移后使用的是新节点的网卡 mac，但该 mac 未被交换机放行。
检查步骤必须按顺序做：
- 在目标节点执行
ifconfig -a，确认 VIP 对应的公网网卡（如eth0）处于 UP 状态，且无NO-CARRIER或LOWER_UP缺失 - 用
ethtool eth0查看 Link detected 是否为 yes；若为 no，物理链路或交换机端口已断开 - 登录交换机，查该端口的 MAC 地址学习表：
show mac address-table interface Gi1/0/5（以实际端口为准），确认是否只学到一个 MAC（即原节点的），而新节点的 MAC 未出现 - 查该端口是否启用 Port Security：
show port-security interface Gi1/0/5，若Security Violation Count> 0 或Security Action是shutdown，基本可锁定问题
ora.net1.network 资源 offline 导致 VIP 无法启动
所有 VIP 都依赖 ora.net1.network（或类似命名的网络资源）。一旦它 offline，VIP 必然跟着失败——哪怕网卡本身 up，只要 Clusterware 认为“网络不可用”，就不会尝试绑定 VIP。
典型原因包括：
- 网卡配置中缺失默认网关（
route -n看不到 0.0.0.0 对应的网关条目），尤其在多网卡环境容易漏配 - 网关 IP 不可达：用
ping -c 3 <gateway_ip>测试，注意必须从 VIP 所属网段的网卡发包（ping -I eth0 <gateway_ip>） - CVU 资源阻塞：若
ora.cvu仍 online 且依赖公网资源，CRSD 会卡在“等待所有依赖资源停止”阶段，导致ora.net1.network无法重启。此时需先srvctl stop cvu再crsctl start res ora.net1.network
USR_ORA_IF 属性错误导致 VIP 绑定到私网网卡
VIP 必须绑定在公网网卡上，但有时 crs_stat -p ora.node1.vip 输出里 USR_ORA_IF=eth1|eth2 包含了私网网卡名（如 eth1 是 priv 网卡），就会导致 VIP 漂移时“飘到私网”——现象是 ip addr show 在目标节点看到 VIP 出现在 eth1 上，但客户端完全无法访问。
修正方法分三步：
- 导出当前配置：
crs_stat -p ora.node1.vip > /tmp/ora.node1.vip.cap - 编辑该文件，将
USR_ORA_IF=后面的值**严格限定为公网网卡名**（如eth0），删掉所有其他网卡（特别是私网名） - 停资源、更新 OCR、再启：
crs_stop -f ora.node1.vip→crs_register -u ora.node1.vip→crs_start ora.node1.vip
SCAN Listener 不接管漂移后的 VIP 连接请求
这不是 VIP 本身的问题，而是客户端连接逻辑的盲区。即使 VIP 成功漂移到 node2，若客户端 tnsnames.ora 中只写死两个 VIP 地址，首次连接仍会尝试已宕机的 node1-vip，并卡在 TCP connect timeout（默认 60 秒）才切到 node2-vip。
真正解耦故障与连接的关键是 SCAN：
- 确保所有节点的
remote_listener参数指向 SCAN 地址：ALTER SYSTEM SET remote_listener='rac-scan:1521' SCOPE=BOTH; - DNS 必须返回全部三个 SCAN IP（不能写死
/etc/hosts），且轮询生效（nslookup rac-scan多次执行应看到不同 IP） - 检查 SCAN Listener 状态：
lsnrctl status LISTENER_SCAN1，输出中必须包含Service "rac.db" has 2 instance(s)，且两个实例状态都是 READY
交换机 MAC 绑定和网卡接口属性（USR_ORA_IF）这两处，最容易被忽略——它们不报错，但会让 VIP 表面“在线”，实则无法响应任何连接请求。
