根本原因是数据库processes或sessions参数耗尽，导致监听器无法分配新进程，虽显示READY但拒绝连接；具体表现为TNS-12519日志、lsnrctl services中Handler(s)状态blocked、v$process/v$session接近上限。
为什么lsnrctl status显示READY，但连接仍被拒绝？
根本原因常不是监听没跑，而是它启动后无法为新连接分配资源——oracle监听器本身不直接处理sql，但它要为每个入站连接fork一个oracle进程（或调度到现有进程）。一旦数据库的processes或sessions参数耗尽，监听器会在日志里记下tns-12519: tns:no appropriate service handler found，然后静默丢弃后续连接请求。这个错误不会出现在客户端报错里，客户端看到的往往是ora-12514或直接超时，容易误判为配置问题。
processes和sessions的实际约束关系
这两个参数是硬性上限，且存在固定换算： sessions = (1.5 × processes) + 22。监听器每接受一个新连接，就要消耗1个processes配额；如果启用了共享服务器模式，还会额外占用sessions。一旦达到上限，lsnrctl services输出中对应服务的Handler(s)状态会变成blocked或数量停滞不动。
-
processes控制操作系统级进程/线程总数，包括后台进程（PMON、SMON等）、用户连接、RMAN会话、甚至DB Link发起端 -
sessions是逻辑会话数，包含processes所含的所有连接，也包含递归会话（如触发器内发起的查询） - 修改任一参数都需重启实例生效，不能
ALTER SYSTEM动态调整
快速确认是否真被参数卡住
别急着改参数，先用三条命令交叉验证：
- 查当前使用量：
SELECT COUNT(*) FROM v$process;和SELECT COUNT(*) FROM v$session; - 查上限值：
SHOW PARAMETER processes和SHOW PARAMETER sessions - 查监听实际受理能力：
lsnrctl services，重点看目标服务名（如ORCL）下的Handler(s)行，若显示established: 0 refused: X且X持续增长，基本锁定
注意：v$process满并不一定意味着连接满——可能是某些进程僵死未释放（比如异常断连后未清理），这时需要结合v$session.status查INACTIVE但LOGON_TIME极老的会话。
调整参数前必须检查的兼容性陷阱
盲目调高processes可能引发底层冲突：
- Linux系统限制：
ulimit -u（最大用户进程数）必须 ≥ 设置的processes值，否则实例启动失败，报ORA-27300 - Windows服务账户权限：若以本地系统账户运行OracleServiceORCL，
processes > 500时可能因会话池耗尽而无法创建新线程 - 内存压力：每个
process默认占用约10MB PGA+UGA，设为2000会多占20GB内存，可能触发ORA-04030 - 监听器自身也有隐式限制：19c默认最大并发连接由
listener.ora中MAX_CONNECTIONS控制（未显式配置时≈processes × 0.8），超过也会拒绝
真正关键的点是：监听器能否把连接“交出去”，取决于数据库有没有空闲process槽位。很多团队花几小时调listener.ora，最后发现只是processes=300被298个长连接占满了——该杀会话，不是该改监听。
