scan监听器端口修改必须通过srvctl重建，同步更新scan vip、local_listener参数、客户端连接串及防火墙策略，否则导致连接失败。
scan监听器不是普通监听器，不能用lsnrctl直接改端口
oracle rac 的 scan 监听器由 clusterware 全权管理，和单机的 listener.ora 完全隔离。你用 lsnrctl stop 或手动改配置文件，clusterware 下一秒就会把它拉起来——而且还是原来端口。这不是权限问题，是设计使然。
- SCAN 监听器必须通过
srvctl管理，其他方式均无效 - 端口修改本质是“重建”：先移除旧实例，再用新端口添加
- 操作前确认所有客户端已适配新端口（JDBC URL、tnsnames.ora 中的
PORT），否则连接直接中断
srvctl add scan_listener 会失败？检查 SCAN 名称和网络配置是否匹配
常见报错：PRCR-1079 : Failed to start resource ora.scan1.net 或 CRS-2566: Invalid network specified。根本原因不是命令写错，而是 SCAN 名称没解析或对应网络未在 OCR 中注册。
- 运行
srvctl config scan确认 SCAN 名称（如rac-scan.example.com）已在 DNS 或 GNS 解析出 3 个 A 记录 - 运行
oifcfg getif查看集群使用的公网上网卡名（如eth0），确保srvctl add scan_listener -l LISTENER_SCAN1 -p 1522中的网络与之匹配 - 若使用 GNS，
-n参数必须指定 GNS VIP 名；若用 DNS，则无需-n
修改 SCAN 监听器端口必须配套更新 SCAN VIP 和数据库本地监听器
只改 SCAN 监听器端口，不碰 SCAN VIP 和数据库的 local_listener，会导致客户端能连上 SCAN，但后续连接重定向失败（ORA-12514 或超时）。
- SCAN VIP 默认绑定 1521，若 SCAN 监听器改到 1522，需同步执行：
srvctl modify scan -i 1 -p 1522（注意：1522 是 SCAN VIP 端口，不是监听器端口——但 Oracle 要求二者一致） - 数据库中执行：
ALTER SYSTEM SET local_listener='(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=rac-scan.example.com)(PORT=1522)))' SCOPE=BOTH; - 验证：
lsnrctl status LISTENER_SCAN1显示端口为 1522，且SELECT * FROM V$LISTENER_NETWORK;中 PORT 字段也应为 1522
生产环境改端口前务必停掉依赖 SCAN 的业务，并验证 TNS 连通性
SCAN 端口变更后，即使集群状态正常，客户端仍可能因缓存、驱动限制或防火墙策略失败。最容易被忽略的是 JDBC Thin 驱动对非标准端口的兼容性。
- Java 应用若用
jdbc:oracle:thin:@rac-scan.example.com:1521/service，必须同步改为 1522；否则连接池初始化就报IO Error: The Network Adapter could not establish the connection - Linux 客户端需确认
/etc/hosts未静态绑定 SCAN 名称（会绕过 DNS，导致端口不生效） - 防火墙规则要同时放开新端口（不仅是数据库服务器，SCAN VIP 所在节点的 OS 防火墙也要放行）
SCAN 监听器端口不是孤立配置项，它牵扯 SCAN VIP、数据库参数、客户端连接串、网络策略四层联动。漏掉任何一层，都会让“改端口”变成“断服务”。
