修改 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。
