srvctl stop scan_listener 后新连接失败是因为监听进程被杀但 SCAN VIP 未迁移、内核连接表未清空，导致 TCP SYN 无响应而连接不稳定；需同步检查 DNS 解析、OCR 中 SCAN VIP 状态及客户端连接池配置。
srvctl stop scan_listener 为什么连不上新连接
停掉 scan_listener 后，旧连接可能还在，但新客户端连不上 scan vip，因为监听进程确实没了，但底层 vip 和网络栈没重置。这不是“没生效”，是 oracle 的 scan 架构决定的：客户端靠 dns 解析 scan 名称得到三个 ip，再轮询连其中一个；srvctl stop scan_listener 只杀监听进程，不挪 vip，也不清空内核连接表。
- 真实现象：
lsnrctl status显示监听未运行，但nc -z scan-name 1521偶尔通、偶尔超时，或直接被拒绝 - 根本原因：VIP 还挂在某个节点网卡上，但没监听进程响应，TCP SYN 包发过去没人 ACK，部分系统会缓存 RST 或超时行为，导致连接表现不稳定
- 别指望只 stop/start 就能“刷新连接”——它不清理已建立的数据库会话，也不驱逐客户端连接池里的 stale socket
srvctl start scan_listener 启不来？检查 OCR 和 VIP 状态
srvctl start scan_listener 失败常见于依赖项异常，不是监听配置本身问题。SCAN 监听器强依赖 OCR 中注册的 SCAN VIP 资源，一旦 VIP offline 或状态异常，监听器必然起不来。
- 先查 VIP：运行
crsctl stat res -t | grep scan_vip，确认状态是ONLINE，且在预期节点上 - 再查 OCR 注册：用
srvctl config scan看输出是否含有效 SCAN 名称和三组 IP；若报错PRCR-1076 : Failed to retrieve configuration，OCR 损坏或 GI 用户权限不对 - 参数差异：11gR2 起 SCAN 监听器默认使用
ENDPOINTS="TCP:1521"，不能手动改端口；改了会导致ora.scan_listener资源无法启动 - 性能影响：SCAN VIP 绑定在公网网卡，若该网卡吞吐瓶颈或丢包率高，
start成功后也会出现连接延迟抖动
真正清理连接得靠客户端和服务端双侧动作
重启监听器只是让新连接可建立，旧连接不会自动断开。数据库里仍存在大量 INACTIVE 状态的会话，客户端连接池也还拿着过期 socket。所谓“清理连接”，本质是打破 TCP 四元组维持，不能只靠 srvctl。
- 服务端快速清理：在数据库中执行
ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE（需提前查v$session过滤machine或program） - 客户端配合：Java 应用要设连接池的
testOnBorrow=true+validationQuery=SELECT 1 FROM DUAL，否则池子里的坏连接还会复用 - 容易踩的坑：用
kill -9杀tnslsnr进程代替srvctl stop，会导致 CRS 认为资源异常，下次start可能报CRS-2674: Start of 'ora.scan_listener' on 'node1' failed - 兼容性注意：12c+ RAC 中，若启用了 GNS，SCAN VIP 由 GNS 管理，
srvctl stop scan_listener实际会触发 GNS 自动漂移，此时查ifconfig可能看不到 VIP，但nslookup scan-name仍返回 IP —— 这是正常行为
SCAN 监听器重启后连不上？优先验证 DNS 缓存和客户端本地 hosts
DNS 解析错误是比监听器本身更常见的“连不上”原因。SCAN 名称必须由集群外 DNS 解析为三个 IP，且这三个 IP 必须和 srvctl config scan 输出一致。任何一层缓存不一致，都会导致客户端连错地址或压根解析失败。
- 在客户端机器执行
nslookup scan-name，看返回的三个 A 记录是否和srvctl config scan完全匹配；不匹配就不是监听器问题，是 DNS 配置或缓存问题 - Linux 客户端可能受
/etc/hosts干扰：如果文件里静态写了scan-name到单个 IP，DNS 查询会被绕过，结果必连失败 - Windows 客户端要注意 DNS 缓存：
ipconfig /flushdns后再试；Java 应用还要加 JVM 参数-Dnetworkaddress.cache.ttl=0，否则 JDK 会缓存 DNS 结果长达 30 秒 - 别忽略 TNSPING：运行
tnsping scan-name，输出里Used parameter files:行会暴露实际读取的sqlnet.ora，确认里面没配错NAMES.DIRECTORY_PATH（比如误删了TNSNAMES）
