SCAN VIP无法启动，90%以上因DNS未返回3个独立IPv4 A记录；Oracle 19c强制校验getaddrinfo()结果，单IP或CNAME会导致srvctl start scan静默失败，须用nslookup确认3行A记录且IP属SCAN网段，禁用/etc/hosts中SCAN条目，并检查端口占用、OCR资源状态及DNS配置一致性。
SCAN VIP无法启动，先查DNS解析是否返回3个A记录
SCAN VIP启动失败，90%以上是DNS没返回3个独立IPv4地址。Oracle 19c起强制校验getaddrinfo()结果，只返回1个A记录或CNAME就直接拒绝启动，srvctl start scan静默失败，srvctl status scan可能显示STOPPED或报CRS-2674。
- 在任意节点执行
nslookup your-scan-name（如nslookup rac-scan.example.com），确认输出含且仅含3行A记录，IP必须全部属于SCAN VIP网段 - 禁用
/etc/hosts中任何SCAN相关条目——RAC节点间通信绕过hosts，会导致部分节点解析成功、部分失败，现象是srvctl status scan输出不一致 - 检查SRV记录：
dig +short _scan._tcp.your-scan-name SRV，必须返回0 5 1521 your-scan-name.，端口必须为1521 - 若用GNS，运行
crsctl stat res -t | grep gns，非ONLINE则先srvctl start gns
确认SCAN VIP端口是否被占用（尤其在持有VIP的节点上）
SCAN监听器绑定的是SCAN VIP（不是节点VIP），端口默认1521。常见错误是只查netstat -tuln | grep :1521，却没限定源IP，漏掉VIP端口占用。
- 先查VIP归属：
srvctl config scan记下3个SCAN VIP；再用ip addr show确认当前哪个节点持有该VIP（SCAN VIP浮动） - 在持有VIP的节点上，精确检查：
ss -tuln src <code>SCAN_VIP:1521（如ss -tuln src 192.168.10.101:1521） - 常见冲突源：
lsof -i @<code>SCAN_VIP:1521比netstat更准，能抓到docker容器、遗留tnslsnr进程、DBaaS平台预占端口 - 即使
ps -ef | grep tnslsnr无输出，也可能因防火墙DROP后socket处于TIME_WAIT但端口未释放，临时缓解：echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
OCR资源状态异常导致SCAN VIP注册失败
srvctl add scan不是万能命令，它依赖OCR中已有网络资源和完整GI结构。若OCR损坏或SCAN相关资源被误删，命令会报PRCR-1076或静默失败。
- 运行
srvctl config scan，若输出为空，说明SCAN元数据已丢失 - 验证OCR中仍有网络资源：
crsctl stat res -t | grep scan.*network，若无输出，需先srvctl add network同步子网配置 - 确认public网络定义一致：
srvctl config network，若子网变更或网卡名不匹配（如从eth0变成ens33），srvctl add scan必失败 - 执行
srvctl add scan前，必须确保crsctl stat res -t | grep gns和crsctl stat res -t | grep "ora.*vip"均正常，否则先修复GNS或节点VIP
SCAN VIP状态为UNKNOWN时重点查resolv.conf一致性
一个节点SCAN VIP显示UNKNOWN - CHECK TIMED OUT，其余两个显示ONLINE，典型症状是/etc/resolv.conf在各节点不一致，或DNS服务器整体不可达。
- 所有节点必须共用完全一致的
/etc/resolv.conf，包括nameserver顺序、search域、timeout选项 - 添加
options timeout:1降低单次DNS查询超时，避免总耗时超过VIP资源检查超时（默认约30秒） - 不要只看
nslookup是否通——它走的是系统默认resolver；用dig @<code>DNS_IPyour-scan-name直连指定DNS服务器，排除本地缓存干扰 - 若集群使用GNS，
crsctl stat res -t | grep gns显示OFFLINE时，srvctl status scan可能仍返回“running”，但实际解析已静默失败
真实环境里最易被跳过的点：SCAN VIP绑定依赖底层链路检测（usr_ora_if配置）、DNS负向缓存会让故障持续数小时、srvctl add scan_listener必须在srvctl config scan有输出之后才可执行——三者任一缺失，都会让后续所有操作变成无效劳动。
