SCAN间歇性失联主因是IP冲突或DNS负向缓存：检查SCAN VIP是否被标记DUP、用arping验证唯一性；确认DNS负向缓存TTL是否过长，改用dig+trace排查；ss和nc验证端口监听真实性；日志中TNS-12545等错误揭示真实原因。
SCAN监听偶尔不响应，先盯住IP地址冲突
scan监听器进程本身没挂，srvctl status scan_listener 显示 running，但客户端 tnsping 超时、应用报 ora-12541，这种“间歇性失联”大概率不是配置错误，而是底层网络层出了问题。最常被忽略的是 ip 地址冲突——特别是 scan vip 漂移到某节点后，该节点网卡上已存在同网段的静态 ip 或其他服务占用了相同地址。
检查方法很直接：
- 在每个 RAC 节点上执行
ip addr show，确认所有 SCAN VIP（如10.10.10.44/32）是作为 secondary 地址绑定在 public 网卡（如ens33）上，且未被标记为DUP（duplicate） - 用
arping -D -I ens33 10.10.10.44测试地址唯一性（-D 表示 duplicate detection），若返回 “Received reply”，说明局域网内已有设备响应此 IP，冲突成立 - 检查交换机端口 MAC 地址表，确认 SCAN VIP 对应的 MAC 是否在多个端口出现（二层环路或虚拟机克隆常见诱因）
注意：crsctl stat res -t 不会报 IP 冲突，它只管资源注册状态；而 lsnrctl status LISTENER_SCAN1 卡在 “Connecting to …” 也可能是底层 socket 绑定失败，但错误日志里不会明说——得看 $GRID_HOME/log/<node>/agent/<agent_name>/oraagent_grid.log</agent_name></node> 中是否有 Failed to bind address 类似记录。
DNS负向缓存导致SCAN解析失败
客户端第一次连 SCAN 失败后，后续几分钟反复重试仍失败，nslookup rac-scan.example.com 在客户端机器上能查到 3 个 A 记录，但在应用服务器上却只返回一个或超时——这往往是 DNS 负向缓存（Negative Caching）惹的祸。当某次 DNS 查询返回 NXDOMAIN 或 REFUSED，递归 DNS 服务器会把“查无此名”结果缓存一段时间（TTL 可达数小时），期间所有对该 SCAN 名的解析请求都被直接拒绝，根本不会发往权威 DNS。
这不是 Oracle 的锅，但会表现为 SCAN 不可用：
- 在应用服务器上运行
dig rac-scan.example.com @8.8.8.8 +norecurse，绕过本地递归 DNS 直连公网 DNS，看是否能拿到全部 3 个 A 记录 - 查本地 DNS 服务器（如 dnsmasq、bind）的负向缓存配置：bind 中关注
max-ncache-ttl，dnsmasq 关注neg-ttl参数，默认可能设为 3600 秒 - 临时缓解：在应用服务器的
/etc/hosts中静态写入 3 个 SCAN IP（仅限测试，上线禁用）；长期方案是调整 DNS 服务端负向缓存 TTL 至 30 秒以内，并确保权威 DNS 响应稳定
特别提醒：nslookup 有时会走系统默认 DNS，有时又用 /etc/resolv.conf 第一行，行为不一致；务必统一用 dig +trace 追踪完整解析链路，否则容易误判。
验证 SCAN 监听是否真在监听对应端口
tnsping 成功 ≠ 监听器在收包。tnsping 只校验 TNS 名称解析和 ICMP/UDP 层可达性，不验证 TCP 端口上是否有进程 accept() 连接。所以你看到 tnsping rac-scan.example.com 返回 OK，但应用还是连不上，必须交叉验证端口级连通性。
在任意 RAC 节点上执行：
- 用
ss -tlnp | grep ':1521'查看监听进程绑定的 IP：正确应显示*:1521或具体 SCAN VIP（如10.10.10.44:1521），若只显示127.0.0.1:1521或空，说明监听器没绑定到 SCAN VIP - 从客户端机器执行
nc -zv rac-scan.example.com 1521，观察是否能建立 TCP 握手；若失败，再用tcpdump -i any host rac-scan.example.com and port 1521抓包，确认 SYN 包是否发出、是否收到 SYN-ACK - 不要依赖
lsnrctl status输出里的 “Listening Endpoints Summary” 就认为端口就绪——它只反映监听器内部配置，不反映 OS 网络栈实际状态
一个典型坑：SCAN 监听器配置了多端口（如 1521/1525），但 srvctl modify scan_listener -p "TCP:1521/TCP:1525" 后忘了 srvctl stop/start scan_listener，旧进程仍在跑，新端口根本没加载。
SCAN监听器日志里藏了真实原因
所有表面现象都指向配置或网络，但真正线索往往在日志里。Oracle 不会在控制台报错，但 $GRID_HOME/log/<node>/client/tnslsnr.log</node> 和 $GRID_HOME/log/<node>/agent/<agent_name>/oraagent_grid.log</agent_name></node> 会默默记录每次监听器启停、绑定失败、连接拒绝的细节。
重点关注以下几类行：
-
TNS-12545: Connect failed because target host or object does not exist—— 不是客户端写的 host 错，而是监听器自己尝试反向解析 SCAN VIP 主机名失败（比如 /etc/hosts 缺少 SCAN VIP 的反向解析条目） -
WARNING: Failed to open log file ... permission denied—— grid 用户对日志目录无写权限，导致监听器静默降级，不监听任何端口 -
WARNING: Subscription for node down event returned error—— 集群心跳异常，SCAN 监听器主动退服，此时crsctl stat res -t可能仍显示 ONLINE，但实际已不可用
日志路径中的 <node></node> 是实际节点名（如 rac19c01），不是 hostname；且 grid 用户需有读取权限，别用 root 直接 cat，要用 sudo -u grid tail -n 100 ...。
