scan监听未分发连接主因是客户端未走scan路由或实例未注册，90%源于tnsnames未写全3个scan地址+load_balance=on、remote_listener未指向有效scan名、dns未返回3个a记录三者错位。
SCAN监听没把连接分发到活节点，根本不是它“不干活”，而是客户端压根没走SCAN路由，或服务端实例压根没注册进去——90%的情况跟负载均衡配置、DNS解析、remote_listener三者错位直接相关。
tnsnames.ora里没写全3个SCAN地址 + LOAD_BALANCE=on
Oracle客户端不会自动查DNS补全多个SCAN IP，你写一个ADDRESS，它就只连那一个；写三个但没包在同一个ADDRESS_LIST里，它当你是配了三个不同服务名，根本不会轮询。
-
LOAD_BALANCE = on必须小写on，写成yes、true或ON会被静默忽略 -
HOST字段必须填可被DNS解析的SCAN域名（如rac-scan1.example.com），不能填IP，也不能是CNAME别名 - 三个SCAN地址必须放在同一个
ADDRESS_LIST下，示例如下：
(ORCL_SCAN =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan1.example.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan2.example.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan3.example.com)(PORT = 1521))
)
(CONNECT_DATA = (SERVICE_NAME = orcl))
(LOAD_BALANCE = on)
)
)
remote_listener没指向有效的SCAN名称
实例靠remote_listener参数主动向SCAN监听器广播自己。如果它指向空值、localhost、物理IP，或DNS解析不出3个A记录，注册请求就发不出去——lsnrctl status LISTENER_SCAN1里自然看不到你的服务名。
- 执行
show parameter remote_listener，确认输出是类似rac-scan.example.com:1521的格式 - 用
nslookup rac-scan.example.com验证是否返回3行Address:，少于3个会触发19c+的启动校验失败 - 改完后必须执行
ALTER SYSTEM REGISTER，再等10秒查lsnrctl status LISTENER_SCAN1的Services Summary - 注意：LREG进程只在实例启动时读取
remote_listener，临时修改后仅ALTER SYSTEM REGISTER可能不生效，必要时重启实例
DNS没做轮询或客户端缓存了单个IP
Oracle客户端不主动做DNS轮询，它只按你tnsnames里写的顺序连，且JVM、glibc等会缓存DNS结果。哪怕DNS服务器配置了round-robin，客户端第一次解析后就固定了。
- 在应用服务器上多次执行
tnsping ORCL_SCAN，观察返回的IP是否轮换；始终一样说明DNS轮询未生效或被缓存 - Linux下检查
/etc/nsswitch.conf中hosts: files dns顺序，若/etc/hosts里有SCAN条目，19c会拒绝启动SCAN监听器 - JDBC需显式加
loadBalance=true&failover=true（仅ojdbc8+支持），URL里写jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=...))比用TNS别名更可控 - 临时验证可改
/etc/hosts，但上线禁用——静态绑定破坏SCAN高可用本质
SCAN监听器本身没真正绑定到VIP
srvctl status scan_listener显示ONLINE不代表它真在监听。常见情况是进程起来了，但lsnrctl status LISTENER_SCAN1的Listening Endpoints Summary里HOST字段为空，说明VIP没成功绑定。
- 在节点上执行
ip addr show，确认SCAN VIP作为secondary地址出现在public网卡（如ens33）上，且未标记DUP - 用
arping -D -I ens33 <scan_vip></scan_vip>检测IP冲突，返回Received reply即存在二层冲突 - 查
$GRID_HOME/log/<node>/agent/oraagent_grid.log</node>，搜索Failed to bind address或TNS-12560 - 若发现残留进程，
kill -9后用srvctl start scan_listener -i 1重启，再立刻验证绑定状态
真正难排查的点往往藏在“看似正常”的环节里：比如nslookup在运维机上返回3个IP，但应用服务器上因DNS负向缓存只返回1个；或者lsnrctl status显示服务已注册，但实际注册的是旧SCAN IP，因为srvctl modify scan没同步执行。这些细节不逐层对齐，调参再多也白搭。
