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，搜索这三者是否作为/32secondary 地址出现在 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 值。关键看输出：
- 在持有 SCAN VIP 的节点上执行
lsnrctl status LISTENER_SCAN1 - 重点检查
Listening Endpoints Summary段：必须含(HOST=)(PORT=1521)—— 若HOST=后为空，说明监听器未成功绑定 SCAN VIP，常见于端口被占或 OCR 与 OS 不一致 - 用
ss -tuln src <scan_vip>:1521</scan_vip>（如ss -tuln src 192.168.10.101:1521）确认端口是否真被监听；lsof -i @<scan_vip>:1521</scan_vip>更准 - 若进程存在但无监听，查
$GRID_HOME/log/<node>/agent/oraagent_grid.log</node>，搜索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输出一致；云环境常见eth0vsens192错配 - 执行
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>辅助触发（仅临时诊断）
最易被忽略的是：SCAN VIP 的“漂移”本质是 DNS 解析结果的轮询分发，不是 IP 地址在节点间移动；真正需要动态响应的是 LISTENER_SCANx 进程的启动与绑定。一旦发现 srvctl status scan_listener 显示 UNKNOWN，别急着重启监听，先查 oraagent_grid.log 和 ss -tuln src <vip>:1521</vip>——90% 的 case 卡在这两步。
