SCAN VIP 本身不漂移，始终固定在 DNS 解析的三个地址上；所谓“漂移失败”实为 SCAN Listener 未在接管节点成功启动或绑定，根源在于监听器资源与 OS 网络状态脱节。

SCAN VIP 本身不漂移，它永远固定在 DNS 解析出的三个地址上；所谓“SCAN VIP 漂移失败”，实际是 SCAN Listener 没能在新接管 SCAN VIP 的节点上启动或绑定——根本问题不在 VIP，而在监听器资源与 OS 网络状态的脱节。

确认 SCAN VIP 是否真被当前节点持有

SCAN VIP 是浮动资源，但它的归属由 CRS 动态决定，crsctl stat res -t 显示 online 不代表 IP 已绑定到网卡。必须登录节点验证：

• 运行 srvctl config scan 记下三个 SCAN VIP（如 192.168.10.101、192.168.10.102、192.168.10.103）
• 在每个节点执行 ip addr show，搜索这三者是否作为 /32 secondary 地址出现在 public 网卡（如 ens33）上
• 若某 SCAN VIP 只出现在 node1，而 node2 上完全没出现，说明 CRS 没把该 VIP 分配给 node2——此时查 crsctl stat res ora.scan1.vip -p 中的 USR_ORA_IF 和 USR_ORA_VIP，再比对 oifcfg getif -global 输出的公网接口名是否一致

检查 SCAN Listener 是否在持有 VIP 的节点上真正监听

即使 SCAN VIP 出现在网卡上，LISTENER_SCAN1 进程也可能未启动、绑定失败或监听端口缺失 HOST 值。关键看输出：

Crypto Sniper Oracle

机构级量化市场预言机，提供订单簿失衡（OBI）、VWAP分析、自动化报告及Telegram预警。

下载

• 在持有 SCAN VIP 的节点上执行 lsnrctl status LISTENER_SCAN1
• 重点检查 Listening Endpoints Summary 段：必须含 (HOST=)(PORT=1521) —— 若 HOST= 后为空，说明监听器未成功绑定 SCAN VIP，常见于端口被占或 OCR 与 OS 不一致
• 用 ss -tuln src <SCAN_VIP>:1521（如 ss -tuln src 192.168.10.101:1521）确认端口是否真被监听；lsof -i @<SCAN_VIP>:1521 更准
• 若进程存在但无监听，查 $GRID_HOME/log/<node>/agent/oraagent_grid.log，搜索 Failed to bind address 或 TNS-12560

验证 DNS 解析是否满足 Oracle 19c 强制要求

Oracle 19c 启动 SCAN Listener 前调用 getaddrinfo()，只接受 ≥2 个独立 IPv4 A 记录。返回单 IP、CNAME 或仅一个 A 记录都会导致静默失败：

• 在任意节点执行 nslookup rac-scan.example.com，输出必须严格为三行 Address:，且 IP 全部属于 SCAN 网段
• 禁用 /etc/hosts 中所有 SCAN 相关条目——哪怕写三行，19c 也只认作单解析源，直接拒绝启动
• 检查 SRV 记录：dig +short _scan._tcp.rac-scan.example.com SRV 必须返回类似 0 5 1521 rac-scan.example.com.（端口必须是 1521）
• 若用 GNS，先确保 crsctl stat res -t | grep gns 是 ONLINE，否则 srvctl start gns

排查 OCR 与 OS 网络配置是否同步

OCR 记录的 SCAN VIP、网卡名、子网信息，必须与 OS 实际一致。错位会导致 CRS 无法正确分配资源：

• 运行 oifcfg getif -global 确认公网接口名（如 ens33）是否与 ip -br a 输出一致；云环境常见 eth0 vs ens192 错配
• 执行 srvctl config scan 和 srvctl config scan_listener，对比输出的 VIP 数量和顺序是否与 nslookup 结果完全一致
• 若不一致，强制刷新 OCR：srvctl modify scan -u → srvctl modify scan_listener -u，再重启：srvctl stop scan → srvctl start scan
• 注意：修改后必须在所有节点验证 ip addr show，因为 OCR 更新不等于 OS 自动重绑——有时需手工 ifconfig ens33:1 <SCAN_VIP>/32 up 辅助触发（仅临时诊断）

最易被忽略的是：SCAN VIP 的“漂移”本质是 DNS 解析结果的轮询分发，不是 IP 地址在节点间移动；真正需要动态响应的是 LISTENER_SCANx 进程的启动与绑定。一旦发现 srvctl status scan_listener 显示 UNKNOWN，别急着重启监听，先查 oraagent_grid.log 和 ss -tuln src <VIP>:1521——90% 的 case 卡在这两步。