ORA-00020不会在存储过程编译时出现，它仅在数据库接受新连接时触发，表明活跃进程数已达processes参数上限；编译操作复用当前会话进程，不新增进程，因此该错误实际反映的是连接失败而非编译失败。
ora-00020 不会在存储过程编译时出现。
这个错误只在数据库接受新连接请求时触发，表示当前活跃进程数已达到 processes 参数上限。编译存储过程（CREATE OR REPLACE PROCEDURE 或 ALTER PROCEDURE ... COMPILE）本身不创建新用户进程，它复用当前会话的已有服务器进程，因此完全不会触达 processes 限制。
如果你在执行类似 ALTER PROCEDURE p1 COMPILE 时看到 ORA-00020，真正的问题不是编译动作本身，而是你正在使用的这个会话已经无法建立——或者说，你根本没连上数据库。
为什么你会“以为”是编译报错
常见真实场景是：
- 应用或工具尝试连接数据库执行编译语句，但连接被拒绝
- 客户端（如 SQL*Plus、SQL Developer）显示
ORA-00020后直接退出，你误以为后续输入的ALTER PROCEDURE触发了它 - 实际上，
ORA-00020出现在 CONNECT 阶段，根本没走到编译逻辑
你可以验证：运行 SELECT * FROM v$session WHERE username IS NOT NULL; —— 如果查不到自己的会话，说明连接压根没成功。
怎么确认是不是真连上了
- 连接后立刻执行一个轻量查询，比如
SELECT 1 FROM DUAL; - 如果报
ORA-00020，那就不是编译问题，是连接资源枯竭 - 如果能查出结果，再执行
ALTER PROCEDURE ... COMPILE，这时哪怕编译失败（比如语法错），报的也只会是PLS-00XXX或ORA-04043类错误，绝不会是ORA-00020
编译操作本身要防什么
唯一和编译间接相关的是：
- 如果存储过程中包含大量动态 SQL（
EXECUTE IMMEDIATE）或调用了大量 PL/SQL 包，且这些包尚未加载进共享池，可能短暂增加后台解析压力，但这不会导致ORA-00020 - 真正影响编译成功率的是
shared_pool_size不足（报ORA-04031）或对象依赖断裂（报ORA-04062、ORA-04068）
ORA-00020 的根因永远在线程/进程层，不在 PL/SQL 编译层。排查方向必须回到连接来源、会话堆积、v$process 占用和 processes 参数设置。
