vip资源offline的根本原因是集群网络资源未就绪或配置冲突，具体表现为ora.net1.network未启动、oifcfg接口配置缺失/不一致，或vip与public ip不在同一子网，导致cssd拒绝绑定。
ora..vip 资源显示 OFFLINE 的根本原因
VIP 资源处于 OFFLINE 状态，通常不是监听器或数据库实例的问题，而是集群底层网络资源未就绪或配置冲突。直接查 crsctl stat res -t | grep vip 看状态，再立刻执行 crsctl status resource ora.<node_name>.vip</node_name>，重点看输出里的 STATE_DETAILS 字段——它会明确告诉你卡在哪一步：是“Network not online”、“Interface not configured”还是“Failed to bind address”。常见真实原因有三个：
• ora.net1.network 资源没起来（私网/公网网卡未被集群识别）
• oifcfg getif 输出中该节点缺少公网接口，或子网掩码与另一节点不一致
• VIP 地址本身和节点的 Public IP 不在同一个子网（Clusterware 会硬拦截，报 CRS-2672 或 CRS-2674）
检查公网网卡是否被集群真正接纳
别只信 ifconfig 显示 UP，CSSD 只认 oifcfg 注册的接口。运行 oifcfg getif，确认输出里包含类似 eth0 192.168.10.0 global public 的行，且 IP 段和本节点 Public IP 完全匹配。若缺失，说明集群启动时没扫描到该网卡，常见于：
• 网卡名在不同节点不统一（如 node1 是 ens192，node2 是 eth0）
• /etc/hosts 中节点名解析错误，导致 olsnodes -n 返回空或错乱
• 私网网卡被误标为 public，或公网网卡被漏标 —— 这会导致 VIP 绑定失败后自动退为 OFFLINE
为什么 srvctl start vip 失败且无日志输出
srvctl start vip -n <node></node> 命令静默失败，大概率是因为依赖资源未满足。VIP 启动前必须确保：
• ora.net1.network 是 ONLINE（不是 INTERMEDIATE）
• ora.crsd 和 ora.cssd 都已 running
• OCR 中该 VIP 的配置未损坏（可用 ocrdump -stdout | grep -A5 "VIP.*<node>"</node> 快速验证）
若仍失败，去 $GRID_HOME/log/<node>/agent/</node> 下搜 oraagent_grid.log，过滤 bind 和 address already in use —— 很可能该 IP 已被其他进程（如 httpd、keepalived）占用，或系统路由表存在冲突条目（ip route show 查是否有重复网段）
SCAN VIP 和节点 VIP 的启动顺序不能颠倒
SCAN VIP（如 ora.scan1.vip）依赖节点 VIP 存在才能注册监听。如果先手动启 SCAN VIP，而对应节点的 ora.node1.vip 还是 OFFLINE，SCAN 监听会卡在 INTERMEDIATE 状态，反过来又阻塞节点 VIP 的恢复流程。正确顺序是：
• 先确保所有节点的 ora.<node>.vip</node> ONLINE
• 再启 ora.LISTENER_SCAN1.lsnr
• 最后确认 ora.scan1.vip 自动 ONLINE
注意：srvctl config scan 输出为空，说明 GNS/DNS 根本没生效，此时强行启 SCAN VIP 无意义；应先跑 srvctl status scan 定位 DNS 解析异常点
