ORA-00020是数据库实例启动后因processes参数过小、无法承载DBCA等并发连接而触发的资源上限错误；根本解法是用-prelim模式登录并修改spfile中processes（建议800+）及sessions参数，再重启实例。
ora-00020 不是安装时报的错，而是数据库实例启动后、连接请求激增时触发的资源上限错误。你在 21c 安装过程中看到它，大概率是安装脚本（如 dbca）尝试连接刚建好的实例时失败了——根本原因不是安装本身出问题，而是 processes 参数默认值太小，撑不住安装阶段的并发连接。
为什么 21c 安装容易撞上 ORA-00020
Oracle 21c 默认 processes 值仍沿用旧版保守策略（常见为 300 或更低），但 DBCA 在创建数据库、配置监听、运行预检脚本时会密集发起多个后台连接；加上 GUI 工具（如 Oracle Database Configuration Assistant）自身也占用数个会话，很容易瞬间突破阈值。这不是 bug，是参数没适配新版本实际负载。
- 21c 的多租户和自动内存管理会让后台进程数量比 12c 更多
- 如果你在虚拟机或容器里安装，资源受限会进一步放大连接竞争
- 错误日志里出现
ORA-00020: maximum number of processes (300) exceeded，括号里的数字就是当前生效值
安装中途报 ORA-00020 怎么紧急绕过
此时数据库实例已启动但无法登录常规用户，必须用 -prelim 模式连入并调大参数——这是唯一能不中断安装流程的操作路径。
- 新开终端，执行：
sqlplus -prelim / as sysdba - 立即执行：
alter system set processes=800 scope=spfile;（800 是安全起点，生产环境建议 1000+） - 退出：
exit - 回到 DBCA 界面，点击「重试」或关闭后重新启动 DBCA（不要删已建库）
注意：-prelim 模式不建立完整会话，因此不受 processes 限制，但仅支持有限命令（alter system 可用，select 不行）。
安装完成后必须验证的三件事
DBCA 走完流程不代表万事大吉。21c 启动后若未手动验证，下次重启仍可能因 spfile 未生效而回退到旧值。
- 确认参数已写入 spfile：
sqlplus / as sysdba→show parameter processes;，输出值应与你设的一致 - 检查当前活跃进程数：
select count(*) from v$process;，如果接近你设的值（比如 790/800），说明有泄漏，得查v$session - 验证监听是否真正接管：用
lsnrctl status看服务名是否注册成功，避免 DBCA 报错其实是监听没通导致的假性 ORA-00020
别忽略的兼容性细节：21c 的 sessions 计算逻辑变了
processes 和 sessions 不是简单 1:1 关系。21c 中 sessions 默认 = (1.5 * processes) + 22，且启用了动态会话池。如果你只改了 processes 却没同步调整 sessions，某些 JDBC 驱动（尤其老版本）会因会话预分配失败间接触发进程耗尽。
- 保险做法：一起设：
alter system set processes=800 scope=spfile;和alter system set sessions=1220 scope=spfile; - 切勿用
scope=both——21c 的内存自动管理会让both失效，必须走spfile+ 重启 - 改完一定要
shutdown immediate; startup;，光 reload 不生效
最常被跳过的动作是重启后没再查 v$process 实际占用——很多“已修复”案例其实只是临时杀掉了几个会话，没碰根本参数，过两天又爆。
