ORA-12541本质是客户端无法连接监听器，需分层验证：一查tnslsnr进程是否真实运行；二改listener.ora中HOST为真实IP并reload；三用telnet和tnsping测试网络与注册；四排查防火墙、listener.log膨胀等问题。
ORA-12541 错误不是“监听没开”，而是客户端根本连不上监听器——可能进程没跑、绑错了地址、端口被拦，或实例压根没注册。得一层层验，不能只靠 lsnrctl start。
确认 tnslsnr.exe 进程是否真实运行（Windows）或 tnslsnr 是否存活（Linux）
很多人看到 lsnrctl status 显示 “Listener is running” 就停手，但这个输出可能只是连上了默认监听器（比如 LISTENER），而你的连接字符串指向的是另一个监听名，或者 IPC 通道已断，命令返回了缓存结果。
- Windows：打开任务管理器 → 详细信息页 → 搜索
tnslsnr.exe，重点看“用户名”列是不是 Oracle 服务账户（如NT SERVICE\OracleOraDb19c_home1TNSListener） - Linux：执行
ps -ef | grep tnslsnr，确认输出里有类似/u01/app/oracle/product/19c/dbhome_1/bin/tnslsnr的完整路径进程 - 如果没找到进程，
lsnrctl status却报TNS-12560: TNS:protocol adapter error，说明监听器根本没启动，直接执行lsnrctl start，别纠结配置文件
检查 listener.ora 中的 HOST 是否绑定实际 IP
监听进程在跑，但只绑了 localhost 或 127.0.0.1，远程客户端发包过去，操作系统直接丢弃——这就是“假运行”最常见原因。
- 路径：
$ORACLE_HOME/network/admin/listener.ora - 找到类似这一行：
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521)) - 把
HOST = localhost改成服务器真实网卡 IP（如192.168.1.10）或0.0.0.0（仅限可信内网） - 改完必须执行
lsnrctl reload（不是stop/start或restart），否则配置不生效 - 再跑
lsnrctl status，看Listening Endpoints Summary里显示的HOST值是否是你刚填的那个 IP
用 telnet 和 tnsping 分层验证网络与注册状态
tnsping 只验证 TNS 名解析和监听响应，telnet 才能确认 TCP 层通不通；两者都过，才说明监听真正可触达。
- 从客户端机器执行：
telnet 192.168.1.10 1521（IP 和端口必须和连接字符串一致）
→ 若黑屏几秒后退出，表示通；
→ 若提示“连接被拒绝”，说明监听没 bind 到该地址；
→ 若超时，是防火墙或路由问题 - 同一台客户端执行：
tnsping ORCL（ORCL是你连接字符串里的 TNS 别名）
→ 输出里出现OK (xx ms)表示 TNS 解析和监听响应正常 - 若
tnsping成功但应用仍报 ORA-12541，检查数据库实例是否注册：
用sqlplus / as sysdba登录，执行alter system register;，等 30 秒后再查lsnrctl status，看Services Summary里有没有你的SERVICE_NAME
排查防火墙、SELinux 和 listener.log 膨胀问题
监听进程在、配置对、端口也显示监听了，但 lsnrctl status 突然报 TNS-12560 或直接无响应——很可能是日志写满导致监听静默崩溃，或系统策略拦截了新连接。
- Linux 上检查防火墙：
sudo firewall-cmd --list-ports，确认1521/tcp已放行；SELinux 状态用sestatus查，临时关可用setenforce 0 - Windows 防火墙需手动放行
tnslsnr.exe或开放端口 1521 - 检查
$ORACLE_HOME/network/log/listener.log大小，若超过 1GB，清空它（先 stop 监听，清日志，再 start） - 极端情况下，
netca重建监听配置比修旧文件更可靠
最容易被跳过的环节，是改完 listener.ora 后没执行 lsnrctl reload，或 reload 后没看 lsnrctl status 输出里的真实 HOST 值——它不会骗人，但人容易信错输出。
