用 crsctl stat res -t 查看 ora..vip 资源的 STATE 是否为 ONLINE 且 HOST 列显示节点名，即可确认 VIP 当前运行节点；SCAN VIP 不绑定固定节点，VIP 可漂移，不依赖 ip addr 或 ping 结果。
如何用 crsctl stat res -t 快速确认 VIP 当前运行在哪个节点
直接看资源 state 和 host 列——ora.<node>.vip</node> 资源如果显示 online 且后面跟着节点名（如 on node1），那就是它当前绑定的主机。别信 vip 的 ip 地址配置在哪台机器上，rac 里 vip 是可漂移的，只看实时状态。
-
crsctl stat res -t输出中找形如ora.node1.vip或ora.orcl01.vip的行，STATE 必须是ONLINE，不是OFFLINE或UNKNOWN - 同一 VIP 资源不会在多个节点同时为 ONLINE；若出现两个节点都显示 ONLINE，说明 OCR 或网络异常，需立刻查
crsctl check crs和oifcfg getif - 注意区分
ora.<node>.vip</node>（节点级 VIP）和ora.scan*.vip（SCAN VIP），后者不绑定固定节点，由 SCAN Listener 动态分发
为什么 ping 或 ip addr 看到的 VIP 不一定可靠
因为 VIP 是由 Oracle Clusterware 主动管理的浮动地址，不是靠系统 ip addr add 静态配置的。它可能已从网卡上被 CRS 主动摘除（比如节点心跳丢失后触发 relocate），但 DNS 缓存、ARP 表或本地路由表还没刷新，导致你还能 ping 通——这属于“幽灵响应”，不代表服务可用。
- 执行
ip addr show在节点上查不到 VIP？正常。VIP 由ora.cluster_vip_net1.type资源驱动，不依赖传统 ifconfig - 能
ping通 VIP 却连不上数据库？大概率是监听器没起来，或 VIP 已漂走但 ARP 没更新，用srvctl status listener和crsctl stat res -t交叉验证 - 检查真实绑定：在疑似节点上运行
grep "Virtual IP" $GRID_HOME/log/`hostname`/agent/ohasd/orarootagent_root/orarootagent_root.log | tail -5，能看到 VIP 绑定/释放的精确时间戳
常见误判场景：当 crsctl stat res -t 显示 UNKNOWN 或空白时怎么办
这通常不是 VIP 本身出问题，而是 CRS 资源代理没拿到该节点的最新心跳反馈，比如私网中断、CTSS 同步失败、或节点处于 “evicted” 状态但未完全离线。此时不能凭空猜测 VIP 在哪，必须先定位节点健康度。
- 先跑
crsctl check cluster -n，若返回CRS-4537: Cluster Ready Services is online才可信；否则该节点已失联，其 VIP 必然已漂到其他节点 - 若某节点显示
UNKNOWN，立刻查tail -20 $ORACLE_BASE/diag/crs//crs/trace/alert.log，重点搜ORA-15064（ASM 通信中断）、cssdmonitor（心跳超时）、relocate关键字 - 不要手动执行
ifconfig eth0:1 <vip></vip>强绑 VIP——这会与 CRS 冲突，导致资源状态错乱，甚至引发脑裂
真正需要人工干预 VIP 绑定的唯一合理场景
只有在计划内维护（如打 GI 补丁、更换网卡）且明确要求 VIP 必须提前迁移到指定节点时，才用 srvctl relocate vip。其他所有“VIP 漂错了”“VIP 连不上”的问题，本质都是底层故障（网络、存储、时间同步）的表象，强行挪 VIP 只是掩盖症状。
- 迁移命令：
srvctl relocate vip -node -nodelist，执行后必须等crsctl stat res -t | grep vip确认状态变为 ONLINE on 新节点 - 迁移失败常见原因：目标节点 public 网络不通、OCR 中该 VIP 资源未注册（
crsctl stat res ora.<node>.vip</node>报“resource does not exist”）、或目标节点 CRS 未启动 - 记住：VIP 不是负载均衡器，它不参与连接分发；它的唯一使命是快速宣告“本节点已不可用”，把客户端连接请求甩给其他节点——所以它在哪，取决于哪个节点还活着，而不是你想让它在哪
crsctl check ctss 是否为 ACTIVE，或 olsnodes -s 是否所有节点都显示 “Active”。这些才是真正的第一判断依据。
