监听服务显示“已启动”但实际无响应，需用lsnrctl status和netstat验证真实状态，检查listener.ora中HOST是否为真实IP或主机名，清理过大监听日志，确认数据库实例已向监听器注册服务。
监听服务显示“已启动”但实际没响应？先验证真实状态
windows服务管理器里显示 oracleoradb19c_home1tnslistener 是“正在运行”，不代表它真在工作——这是最常被误判的点。很多故障里，服务进程僵死、卡在初始化阶段，或监听端口根本没绑定成功，但服务状态仍维持“运行”假象。
- 必须用命令行实测：
lsnrctl status—— 如果报TNS-12541: TNS: no listener或TNS-12560: TNS: protocol adapter error，说明监听器进程未真正就绪 - 再补一刀：
netstat -ano | findstr :1521—— 若无任何输出，证明 1521 端口根本没被监听，服务只是“挂着名” - Linux 用户直接看进程：
ps -ef | grep tnslsnr，若只有grep自身进程，说明监听器根本没起来
listener.ora 中 HOST 配置写 localhost 就连不上远程？对，就是这个坑
很多人抄模板时习惯把 HOST 写成 localhost 或 127.0.0.1，本地 SQL*Plus 能连，但其他机器一连就报 ORA-12541。原因很简单：监听器只绑定了回环地址，对外部网络请求完全“装聋作哑”。
- 打开
$ORACLE_HOME/network/admin/listener.ora，检查ADDRESS段中的HOST值 - 必须填服务器**真实主机名**（如
db-prod-01）或**实际网卡IP**（如192.168.5.100），不能是localhost - 改完后别直接重启服务，先执行：
lsnrctl reload—— 它会校验语法并热加载配置，避免因格式错误导致启动失败 - 如果不确定主机名是否正确，运行
hostname（Linux）或echo %COMPUTERNAME%（Windows）比猜更可靠
监听日志暴涨到几个G？它可能正在拖垮整个监听进程
监听器本身不崩溃，但日志文件（$ORACLE_HOME/network/log/listener.log）涨到 3GB 以上时，lsnrctl status 会严重卡顿甚至超时，表现为“服务启动了却无法响应”。这不是配置问题，是 I/O 阻塞。
- 查日志大小：
ls -lh $ORACLE_HOME/network/log/listener.log（Linux）或看文件属性（Windows） - 临时缓解：清空日志（
cat /dev/null > listener.log）或重命名归档，再lsnrctl reload - 根治办法：在
listener.ora中添加：LOGGING_LISTENER = OFF，或启用日志轮转（需配合LOG_DIRECTORY_LISTENER和LOG_FILE_LISTENER） - 注意：某些旧版本（如 11g）还受
DIAG_ADR_ENABLED_LISTENER = OFF控制，否则 ADR 日志也会疯长
tnsping 通但应用连不上？检查客户端连接串和服务器端服务名是否对得上
tnsping ORCL 返回 “OK” 只代表网络层能触达监听器，不代表数据库服务注册成功。常见现象是监听器起来了，但数据库实例没向它“报到”，或者服务名拼错了。
- 在服务器上运行：
lsnrctl services，看输出里有没有你连接串中用的SERVICE_NAME（比如ORCL）或SID - 若列表为空或没有对应服务名，说明数据库实例未注册——检查
local_listener参数或确认数据库是否已启动（sqlplus / as sysdba后执行select status from v$instance;） - 客户端连接串（如 JDBC URL 或 tnsnames.ora 条目）里的
SERVICE_NAME必须与lsnrctl services输出中列出的严格一致，大小写敏感，多一个空格都不行 - Windows 上还要留意：若用主机名连接，确保客户端
%WINDIR%\System32\drivers\etc\hosts文件里有对应解析，DNS 失败时不会报 DNS 错误，而是静默降级为ORA-12541
最容易被忽略的是：监听器能启动 ≠ 数据库实例已注册；tnsping 成功 ≠ 应用能连；服务状态正常 ≠ 进程可用。排查时，永远以 lsnrctl status 和 lsnrctl services 的实时输出为准，而不是服务管理器里的那个“绿色对勾”。
