运行lsnrctl status可查看监听器实际监听的端口和地址，lsnrctl show config则显示当前加载的listener.ora路径；若路径不存在或为空，则监听可能采用默认端口1521且未读取静态配置。
确认当前监听真实端口和配置文件路径
别急着改文件，先看监听到底在用哪个端口、读的是不是你手里的 listener.ora。运行 lsnrctl status，重点看 “Listening Endpoints Summary” 行——它显示的是正在实际监听的地址和端口，这才是真相。
再执行 lsnrctl show config，它会输出当前加载的配置文件路径。如果显示 No listener.ora file found，说明监听是纯动态启动的，没读任何静态配置文件，你改了 listener.ora 也没人认。
- 若
show config显示路径但文件不存在，得先创建标准listener.ora（不能留空） - 若路径存在但内容为空或只有注释，监听可能 fallback 到默认行为（1521），需补全 ADDRESS 段
- Windows 上注意服务名可能带版本号（如
OracleOraDB21Home1TNSListener），改完要确认服务是否真在用这个配置
改 listener.ora 时必须同步更新的三处位置
只改 (PORT = 1521) 这一处？大概率连不上。Oracle 的注册、解析、连接链路里多处隐式依赖端口一致。
以改成 1522 为例，以下三处都要动：
-
(ADDRESS = (PROTOCOL = TCP)(HOST = your-hostname)(PORT = 1521))→ 把1521改成1522 -
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))→ 虽然 IPC 不走网络，但 KEY 名含旧端口号易引发误判，建议同步改为EXTPROC1522 - 检查是否有
ADR_BASE_LISTENER或日志路径（如LOG_DIRECTORY_LISTENER）含端口号，一并更新，否则查日志时容易混淆
保存时注意编码：Linux 下用 vi 或 sed -i；Windows 上别用记事本另存为，否则可能变成 GBK 编码导致监听启动失败。
改完不 reload 或 stop/start 就等于没改
lsnrctl reload 是热加载，不中断已有连接，但它不会清理旧端口上的已注册服务。比如之前用 1521 注册的实例，reload 后可能还在老端口挂着。
更稳妥的做法是冷启动：
- 先
lsnrctl stop - 再
lsnrctl start - 最后用
lsnrctl services确认输出里只出现新端口（如1522），且对应实例的STATUS是READY
如果看到新旧端口同时存在，大概率是多个 listener.ora 被误加载，或者有另一个监听进程在后台跑着（ps -ef | grep tnslsnr 查一下）。
客户端配置和数据库参数必须同步更新
服务器端改完监听端口，客户端照样连老端口——因为 tnsnames.ora 和 JDBC URL 里写的还是 1521。
必须同步操作：
- 所有用到该库的客户端（应用服务器、开发机、DBA 工具）的
$ORACLE_HOME/network/admin/tnsnames.ora，找到对应服务名段，把(PORT = 1521)改成新端口 - 登录数据库执行：
alter system set local_listener="(address=(protocol=tcp)(host=your-hostname)(port=1522))"—— 否则动态注册仍往 1521 上报，新监听收不到服务注册 - 防火墙必须放行新端口（
iptables或系统防火墙规则），否则telnet host 1522直接超时
最容易被忽略的是 local_listener 参数：很多环境初始为空，改端口后不设它，监听就收不到实例注册，lsnrctl services 里看不到你的库，但 lsnrctl status 显示正常——这种“半通”状态最难排查。
