“not currently running”但进程存在，说明lsnrctl无法通过ipc与tnslsnr通信，主因是listener.ora中host配置错误或端口被占用；需查进程、端口绑定及listener.log中的tns-12560/tns-12535错误。
lsnrctl status 显示“not currently running”但进程存在？
这种情况说明 lsnrctl 无法通过 IPC 通道与 tnslsnr 进程通信，不是监听器没起，而是它启动后没正确加载配置或绑定失败。常见于：listener.ora 中 HOST 指向了不存在的网卡名，或 PORT=1521 被其他进程（如另一个 Oracle 实例、PostgreSQL）占用了。
验证方式：
- Linux 下执行
ps -ef | grep tnslsnr，确认进程存在； - 再执行
netstat -tuln | grep :1521，看端口是否真被tnslsnr占用； - 检查
$ORACLE_HOME/network/log/listener.log最后几行，重点找TNS-12560（协议适配器失败）或TNS-12535（超时），这类错误通常出现在启动日志里，比status命令更早暴露问题。
telnet server_ip 1521 失败但 lsnrctl status 显示 ready？
这说明监听器在本地能响应管理命令，但对外不可达——根本原因几乎总是 listener.ora 的 HOST 配置不匹配客户端请求的目标地址。比如你从 192.168.5.100 连服务器 192.168.5.200，而 listener.ora 写的是 (HOST = localhost)，监听器就只绑在 127.0.0.1，外部 TCP 连接必然被拒绝。
修复要点：
- 把
HOST改成服务器实际 IP（如192.168.5.200）或通配符0.0.0.0（需配合防火墙策略）； - 改完不要
lsnrctl stop/start，用lsnrctl reload生效，避免中断已有连接； - Windows 用户注意：服务名可能含版本号（如
OracleOraDb19c_home1TNSListener），reload前先确认服务已运行，否则命令无响应。
ORA-12541 出现在 JDBC 或应用日志里，但 SQL*Plus 本地能连？
这说明监听器对本机回环地址（127.0.0.1:1521）是通的，但对远程客户端不可见。问题不在监听器本身，而在网络路径上。典型干扰项有：
- 服务器防火墙（
iptables/firewalld/ Windows Defender 防火墙）未放行1521端口； - 云平台安全组规则未开放入方向 TCP:1521；
- 客户端连接串里的
HOST是主机名，但 DNS 或/etc/hosts未解析到服务器真实 IP； - 中间有 NAT 设备，客户端发包目标 IP 和端口被修改，导致监听器收不到原始请求。
最简验证法：telnet server_ip 1521 从客户端机器直连，不通就停在这步查网络层，别急着动 Oracle 配置。
监听器启动成功且端口可达，仍报 ORA-12541？
极少数情况是客户端缓存或连接串误用 Easy Connect 语法却漏写端口。例如写成 sqlplus user/pass@db-server/SERVICE_NAME，默认走 1521，但如果监听器实际监听在 1522，就会静默失败并报 12541。
排查建议：
- 用完整描述符连接测试：
sqlplus user/pass@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=server_ip)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ORCL)))； - 检查客户端
tnsnames.ora对应别名中HOST和PORT是否与服务器实际监听一致； - Java 应用若用
jdbc:oracle:thin:@host:port:service_name格式，注意port是监听端口，不是数据库实例端口（Oracle 没有“实例端口”，只有监听端口）。
真正容易被忽略的是：监听器日志文件（listener.log）长期不清理会膨胀到 GB 级，导致新连接尝试写日志失败，进而使监听器进入半死状态——status 看似正常，services 却为空，reload 也无效。遇到反复重启无效的情况，先清日志再试。
