直接改processes即可，sessions通常由oracle按1.1×processes+5自动计算，手动设置易引发ora-00020或结构异常；必须用alter system set ... scope=spfile并重启，且确保ulimit -u≥新processes值。
直接改 processes 就行，sessions 大部分时候不用手动设——oracle 会按公式自动算，硬设反而容易出错。
查当前值别信文档，默认值不等于实际值
初始化参数文件（spfile/pfile）里怎么写，数据库就怎么跑。查出来的值才是真实生效的限制。
- 用
SELECT name, value FROM v$parameter WHERE name IN ('processes', 'sessions');最准，v$parameter是运行时视图，反映实例当前配置 -
SHOW PARAMETER processes也能看，但注意它只显示已加载的参数，如果实例没正常启动，可能返回空或 0 - 如果查出来
value = 0，说明实例没起来，或者用了隐含参数，先SELECT status FROM v$instance;确认状态
改 processes 必须用 SCOPE=SPFILE 并重启
processes 是静态参数，ALTER SYSTEM 不能动态改；写进内存（SCOPE=MEMORY）无效，写进 spfile 才是真改。
- 正确命令：
ALTER SYSTEM SET processes = 500 SCOPE=SPFILE; - 错误操作：
SCOPE=BOTH或SCOPE=MEMORY—— 执行成功但重启后还原 - 改完必须
SHUTDOWN IMMEDIATE再STARTUP，ALTER SYSTEM RELOAD对这个参数完全没用 - 重启失败？立刻检查系统级限制：
ulimit -u（Linux 用户最大进程数），它必须 ≥ 新的processes值，否则 Oracle 实例根本起不来
别乱动 sessions，除非你清楚连锁影响
sessions 不是独立资源池，它依赖 processes：每个会话都要占一个进程槽位。Oracle 默认按 1.1 * processes + 5（19c+ 是 1.5 * processes + 22）推导，这个值已经预留了后台进程开销。
- 手动设
sessions只在一种场景合理：应用连接池明确控制活跃会话数，且你确认它远低于processes限额，才略调高避免ORA-00018 - 设
sessions > 1.5 * processes在 12c 以前版本可能导致共享池结构异常，19c+ 虽支持SCOPE=BOTH动态改，但前提是当前processes还有余量，否则照样拒绝 - 报
ORA-00020（processes 耗尽）时，只调sessions完全没用——进程都没了，会话根本建不起来
连不上不一定是参数问题，先看错误码再动手
Oracle 报错会直接告诉你卡在哪一层，别凭感觉猜。
-
ORA-00020: maximum number of processes (%s) exceeded→ 操作系统进程资源见底，查v$process行数是否接近processes值，优先扩容processes -
ORA-00018: maximum number of sessions exceeded→ 应用层连接泄漏概率更高，查v$session里status = 'INACTIVE'且logon_time很老的会话 - RAC 环境下，每个节点独立计算
processes，别把所有会话数加起来去比单节点参数 - 监听器也可能拦截：检查
listener.ora是否配了MAX_PROCESSES，它会在连接到达实例前就拒绝请求
真正卡住的时候，往往不是参数设小了，而是 processes 改了但 ulimit -u 没同步，或者应用连上不释放、连接池配置失当——参数只是最后一道闸，前面漏水，光加高水坝没用。
