SCAN监听器无法启动主因是SCAN名称解析失败或SCAN VIP端口被占，需先用nslookup验证3个A记录、用ss检查VIP端口占用，而非修改listener.ora。
scan监听器无法启动，90%以上是scan名称解析失败或vip端口被占——先查这两项，别急着改listener.ora。
SCAN名称解析失败会导致TNS-01184和TNS-01183错误
SCAN（Single Client Access Name）不是本地host文件能解决的，它必须由集群DNS或GNS解析为3个IP（RAC默认配置）。如果nslookup scan-name只返回1个IP、超时、或返回非VIP地址，srvctl start scan必然失败。
- 在任意节点执行：
nslookup your-scan-name（如nslookup rac-scan.example.com），确认返回3个A记录，且全部属于SCAN VIP网段 - 检查DNS服务器是否启用SRV记录：
dig +short _scan._tcp.your-scan-name SRV—— Oracle 19c RAC要求该记录存在并指向正确端口（默认1521） - 若用GNS，确认
crsctl stat res -t | grep gns显示ONLINE；GNS宕机时，SCAN解析会静默失败，lsnrctl status却可能显示“监听已启动”但实际不响应 - 切勿在
/etc/hosts里硬写SCAN名——RAC节点间通信会绕过hosts，导致部分节点解析成功、部分失败，现象是srvctl status scan输出不一致
SCAN VIP端口被占用会触发TNS-12545和ORA-12537
SCAN监听器绑定的是SCAN VIP（不是节点VIP），端口默认1521。但很多用户只查netstat -tuln | grep :1521在本机，漏掉SCAN VIP所在网卡的监听状态。
- 先确认SCAN 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）精确检查该VIP+端口是否被占 - 常见冲突源：
oracle用户下的遗留tnslsnr进程（非CRS托管）、docker容器映射了1521、或DBaaS平台预占端口；lsof -i @<code>SCAN_VIP:1521比netstat更准 - 注意：即使
ps -ef | grep tnslsnr没看到进程，也可能有内核级端口占用（如防火墙规则DROP后重试导致socket处于TIME_WAIT但端口未释放），此时需echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse临时缓解
srvctl start scan报错CRS-2674或CRS-5702时优先看OCR和网络资源依赖
SCAN监听器启动失败常被误判为配置问题，实则是底层资源未就绪。CRS不会等DNS超时，而是直接报依赖失败。
- 运行：
crsctl stat res ora.scan1.vip -p | grep -E "(SCAN|HOST|IFNAME)"，确认SCAN_NAME、SCAN_PORT与DNS一致，且IFNAME对应物理网卡（非bond或vlan子接口，除非明确配置支持） - 检查OCR中SCAN配置是否损坏：
ocrdump -stdout | grep -A5 -B5 SCAN—— 若输出为空或含INVALID字段，说明OCR里SCAN元数据异常，需用srvctl remove scan+srvctl add scan重建（注意：这会短暂中断连接） - 验证网络资源就绪：
crsctl check cluster -all和crsctl stat res -t | grep network必须全部ONLINE；若ora.net1.network异常，SCAN监听器绝不可能启动 - 不要手动
lsnrctl startSCAN监听器——它由CRS全权管理，手工启动会脱离CRS管控，后续srvctl stop scan可能失效
SCAN监听器的问题几乎从不发生在listener.ora本身，而在于它运行所依赖的三层基础设施：DNS/GNS解析层、VIP网络层、CRS资源管理层。任何一个环节有毫秒级延迟或配置偏差，都会表现为“监听器无法启动”，但日志里往往只有模糊的TNS-12537或CRS-2674。动手前，先用nslookup和ss锁死前两个环节，比反复重启服务有效得多。
