SCAN Listener是集群级入口，负责接收SCAN IP请求并负载转发；本地LISTENER仅处理本机实例注册和连接，二者分工协作而非并列，需确保LOCAL_LISTENER指向本机真实地址、REMOTE_LISTENER设为可解析的SCAN名称，并手动触发ALTER SYSTEM REGISTER生效。
SCAN Listener 和本地 LISTENER 不是并列关系，而是分工协作
很多人以为要“手动配两个监听器”，其实 oracle rac 中 scan listener 是集群级入口，负责接收客户端通过 scan ip 发来的连接请求；而每个节点上的本地 listener（默认名 listener）只管本机实例注册和本地连接。它们不抢端口、不互斥，但必须注册一致——否则客户端连 scan 能通，却分配不到实例。
关键点在于：实例只向本地 LISTENER 注册；SCAN Listener 本身不直连实例，它靠 OCR 中的集群服务信息做负载转发。所以你改本地监听配置，不影响 SCAN 行为；但改错本地监听的 LOCAL_LISTENER 参数，SCAN 就找不到你这台实例了。
-
LOCAL_LISTENER参数必须指向本机真实监听地址（如(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip)(PORT=1521)))），不能写成localhost或127.0.0.1 -
REMOTE_LISTENER必须设为 SCAN 名称（如rac-scan:1521），且该名称要在所有节点的/etc/hosts或 DNS 中可解析 - 检查是否生效：
lsnrctl status LISTENER看有没有显示 “Service “your_db” has 1 instance(s)”；再用srvctl config listener确认 SCAN Listener 端口和网络绑定正确
修改 LOCAL_LISTENER 后必须手工 reload 实例注册
改完 LOCAL_LISTENER 参数（无论是 ALTER SYSTEM SET 还是改 spfile），实例不会自动重新向监听器注册。这时候 lsnrctl status 里可能还挂着旧地址，SCAN 也就继续忽略你这个节点。
常见错误现象：节点重启后实例没注册进本地监听，SELECT inst_name FROM v$active_instances 看不到自己，但 crsctl stat res -t 显示数据库资源是 ONLINE 的——其实是“活着但不可见”。
- 执行
ALTER SYSTEM REGISTER;强制触发一次动态注册（无需重启实例） - 如果注册失败，先确认本地监听已启动：
lsnrctl status LISTENER；再检查监听日志（默认在$ORACLE_HOME/network/log/listener.log）是否有 TNS-12545 或 TNS-00515 错误 - 别依赖“等两分钟自动注册”——生产环境建议立即手动触发
SCAN Listener 端口被占用或绑定失败的典型表现
SCAN Listener 默认用 1521，但它不是由 listener.ora 控制，而是由 Grid Infrastructure 管理。如果你在节点上手动启了一个普通监听占了 1521，srvctl start scan_listener 会静默失败，crsctl stat res -t 里看到的是 OFFLINE，但没报错提示。
使用场景：升级后 SCAN Listener 消失、新增节点后客户端连 SCAN 超时、tnsping rac-scan 成功但 sqlplus /@rac-scan:1521/orcl 报 ORA-12541。
- 查 SCAN Listener 状态：
srvctl status scan_listener，失败时补看crsctl stat res ora.scan1_listeners -p | grep ENDPOINTS - 查端口占用：
netstat -tlnp | grep :1521（注意是 root 权限），重点看是不是grid用户进程在用 - 不要去改
listener.ora绑 SCAN Listener——它不由该文件控制；要用srvctl modify scan_listener -p 1522改端口，然后srvctl stop/start scan_listener
客户端连接串里写 SCAN 还是节点 VIP？
写 SCAN 是标准做法，但前提是你的 tnsnames.ora 配置和服务名解析都对。容易被忽略的是：SCAN 名称必须能被客户端解析（DNS 或 hosts），且不能和本地节点名冲突；否则 Oracle 客户端会优先走本地解析，绕过 SCAN 负载均衡逻辑。
性能影响明显：用节点 VIP 直连，就彻底绕过了 SCAN 的连接负载分发和故障转移能力；而 SCAN + 连接池（如 UCP、TNSPING）才能真正利用 RAC 的高可用性。
- 推荐连接串格式：
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=rac-scan)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=orcl)))
- 验证是否走 SCAN：
sqlplus /@orcl登录后执行SELECT sys_context('USERENV','SERVER_HOST') FROM DUAL;，返回值应该是某节点 VIP 主机名，而不是 SCAN 名——说明已成功路由 - 如果客户端是 Windows 且 hosts 文件里写了
rac-scan到某个节点 IP，那它永远只连那个节点，SCAN 形同虚设
LISTENER → REMOTE_LISTENER（即 SCAN）→ 客户端。任一环的地址写错、解析失败、端口冲突，都会让 SCAN 看不见这个实例。 
