SCAN Listener默认仅在部分节点运行属正常设计，由Clusterware自动调度与故障转移，只要SCAN VIP资源ONLINE即有效；其不直接注册实例，实例服务需通过local_listener和remote_listener正确配置并动态注册。
srvctl status scan_listener 显示监听器只在部分节点运行
scan listener 是由 grid infrastructure 统一管理的集群资源，不是每个节点都必须运行一个进程。它默认只在集群中部分节点（通常是 1 个或 2 个）上活动，其余节点上的 scan listener 处于 offline 状态——这完全正常，不是故障。oracle 通过 clusterware 自动调度和 failover，确保任意时刻至少有一个 scan listener 在线响应客户端连接。
常见错误现象：srvctl status scan_listener 输出显示 “SCAN listener is running on node1”，但 node2 上状态为 “not running”；误以为 node2 缺失监听能力，进而怀疑网络或配置问题。
实操建议：
-
srvctl config scan_listener查看当前 SCAN Listener 的绑定网卡与端口，确认是否与 SCAN VIP 所在子网一致 -
crsctl stat res -t | grep scan观察ora.scan1.net、ora.scan1.vip等资源状态，只要它们是ONLINE，就说明 SCAN 网络层已就绪 - 不要手动在 node2 上执行
srvctl start scan_listener—— SCAN Listener 启停由 CRS 全局控制，强行启动会触发资源冲突或被自动拉回 OFFLINE - 若所有 SCAN VIP 都无法解析或全部 OFFLINE，优先检查 DNS A 记录是否返回全部 3 个 IP，以及对应网段的防火墙是否放行 1521 端口
lsnrctl services LISTENER_SCAN1 不显示本节点实例服务
SCAN Listener 本身不直接注册数据库实例；它依赖各节点本地 LISTENER 将实例服务动态广播上来。如果 lsnrctl services LISTENER_SCAN1 中看不到某实例（如 ORCL），大概率不是 SCAN 监听器的问题，而是该节点的实例没成功注册进本地监听器，或注册地址不可达。
实操建议：
- 在疑似“掉线”的节点上，用
lsnrctl status LISTENER检查本地监听是否运行，且输出中包含Service "ORCL" has 1 instance(s) - 查实例参数：
SELECT value FROM v$parameter WHERE name = 'remote_listener';，结果应为可解析的 SCAN 名称（如scan-rac.example.com:1521），而非空或 localhost - 查本地注册地址：
SELECT value FROM v$parameter WHERE name = 'local_listener';，值必须指向本机 VIP + 端口（如(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip)(PORT=1521)))），不能是127.0.0.1或主机名未解析 - 执行
ALTER SYSTEM REGISTER;强制刷新注册，5 秒内即可生效，无需重启实例或监听器
DNS 解析 SCAN 名称只返回 1 个 IP，导致客户端始终连同一节点
SCAN 负载均衡的前提是 DNS 对 SCAN 域名返回 3 个独立 A 记录（如 scan-rac.example.com → 192.168.56.20/21/22）。若只配了 1 个 A 记录，或用了 CNAME，客户端每次解析都得到同一个 IP，连接自然全部落到单节点，看起来像“SCAN 只监听部分节点”。
实操建议：
- 在客户端机器上执行
nslookup scan-rac.example.com或dig scan-rac.example.com A，确认返回 exactly 3 条 A 记录，且 IP 地址互不相同 - 禁止使用 CNAME：DNS 中
scan-rac.example.com IN CNAME rac-scan-vip.example.com是无效配置，必须是直接 A 记录 - 若用 /etc/hosts 模拟 DNS，需写满 3 行，例如：
192.168.56.20 scan-rac.example.com<br>192.168.56.21 scan-rac.example.com<br>192.168.56.22 scan-rac.example.com
- 客户端 TNS 连接串中必须用 SCAN 名称（如
scan-rac.example.com），不能替换为某个具体 SCAN VIP —— 否则绕过 DNS 轮询，失去负载分发能力
SCAN Listener 端口被占用或绑定失败却不报错
SCAN Listener 由 Grid Infrastructure 管理，不读取 listener.ora，其端口绑定失败时不会像本地监听那样抛出明显错误。典型表现是 srvctl status scan_listener 显示 “running”，但 lsnrctl status LISTENER_SCAN1 报 TNS-12541: No listener，或 netstat -tlnp | grep :1521 查不到对应进程。
实操建议：
- 检查是否有人在节点上手动启了普通监听占了 1521 端口：
ps -ef | grep lsnr+lsof -i :1521 - 确认 SCAN VIP 已正确绑定到网卡：
ifconfig | grep 192.168.56.20（替换成你的 SCAN IP） - 查看 Grid 日志：
$GRID_HOME/log/<node>/agent/<node>agent/下的gridagent.log，搜索 “SCAN” 或 “port conflict” - 强制重置 SCAN Listener：
srvctl stop scan_listener && srvctl start scan_listener，注意观察命令返回是否静默成功；若失败，crsctl stat res -t中对应资源会标为FAILED
local_listener 指向错误或 remote_listener 解析失败，和 SCAN 本身无关。排查时别陷在 SCAN 进程启停表象里。 
