修改 processes 参数前必须确认依赖关系：它决定最大并发进程数，并连锁影响 sessions（默认=1.1×processes+5）、transactions 及共享池结构；须同步调整 os 层 ulimit -u，且重启实例才生效。

修改 processes 参数前必须确认依赖关系

processes 是 oracle 实例级硬限制，它直接决定最大并发操作系统进程数（包括后台进程、前台进程、调度进程等），而 sessions 的默认值由公式 1.1 * processes + 5 推导得出。改 processes 不等于只改一个数——它会连锁影响 sessions、transactions、甚至共享池中某些固定结构的大小。

常见错误现象：ORA-00020: maximum number of processes (XXX) exceeded 出现后，只调大 SESSIONS 却不碰 PROCESSES，结果重启失败或新会话仍无法建立。

• 修改前先查当前值：SHOW PARAMETER PROCESSES 和 SHOW PARAMETER SESSIONS
• 若用 spfile 启动，必须用 ALTER SYSTEM SET PROCESSES=XXX SCOPE=SPFILE；不能用 SCOPE=BOTH，因为该参数不可动态修改
• 改完必须重启实例，且重启前确保 OS 层 ulimit -u（用户进程上限） ≥ 新的 PROCESSES 值，否则实例起不来

调整 SESSIONS 时优先考虑是否真需要手动设值

SESSIONS 控制的是最大并发用户会话数，但它本身不是独立资源池——每个会话仍需消耗 PROCESSES 中的一个槽位。多数场景下，保持 SESSIONS 为默认计算值更稳妥；手动设死反而容易因公式脱钩导致隐性瓶颈。

使用场景：当应用使用连接池（如 UCP、DBCP），且明确知道最大活跃会话数远低于 PROCESSES 限制时，可略调高 SESSIONS 避免 ORA-00018: maximum number of sessions exceeded，但前提是 PROCESSES 已同步留足余量。

• 若已用 spfile，设值命令是：ALTER SYSTEM SET SESSIONS=YYY SCOPE=SPFILE
• 不要设 SESSIONS > 1.5 * PROCESSES，Oracle 内部结构可能异常（尤其在 12c 以前版本）
• 19c+ 支持 ALTER SYSTEM SET SESSIONS=... SCOPE=BOTH 动态生效，但仅限未超当前 PROCESSES 限额时才真正有效

PROCESSES 调太高会引发 OS 层和内存问题

每个 process 对应一个 OS 进程，意味着更多内存占用（PGA、UGA）、更多文件描述符、更多信号量。盲目翻倍 PROCESSES 可能导致实例启动卡在 “starting background processes”，或数据库运行中出现 ORA-27300 / ORA-27301 类 OS 错误。

性能影响：process 数每增加 100，shared pool 中的 ksupc（process control）结构增长约 2–3MB；大量空闲 process 也会拖慢 v$session 查询响应。

• Linux 下检查当前限制：cat /proc/$(pgrep ora_pmon)/limits | grep "Max processes"
• 临时放宽 ulimit：ulimit -u 4096（需在启动数据库前执行，且要写入 service 或 systemd 配置才持久）
• Windows 上对应的是注册表项 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\Windows 中的 SharedSection 值，改错会导致服务无法启动

验证修改是否生效不能只看 SHOW PARAMETER

SHOW PARAMETER 显示的是当前运行值或 spfile 记录值，不代表实例已按新值加载。特别是 PROCESSES 必须重启才生效，但很多人重启后没验证实际承载能力，上线就出问题。

容易踩的坑：用 SELECT COUNT(*) FROM v$process 查当前进程数，误以为接近 PROCESSES 就“快满了”，其实很多是空闲后台进程；真正关键的是 SELECT COUNT(*) FROM v$session WHERE status='ACTIVE'，再结合应用连接池配置判断压力点。

• 重启后第一件事：查 SELECT name, value FROM v$parameter WHERE name IN ('processes', 'sessions')
• 用 SELECT program, status, COUNT(*) FROM v$session GROUP BY program, status 看连接来源分布，确认是不是某个应用滥占会话
• 如果用 RAC，注意 PROCESSES 是单实例参数，各节点需分别设置，且全局会话数 = 所有节点 SESSIONS 之和（但受 PROCESSES 分布约束）

最常被忽略的一点：修改参数只是治标，真正压垮会话数的往往是应用端连接泄漏、长事务未提交、或数据库链接未正确 close。参数调得再大，也扛不住一个每秒建 50 个 session 却不释放的 bug。