直接修改processes参数即可，sessions由Oracle按公式自动计算（如19c+为1.5×processes+22），手动设置易出错；查真实值应使用SELECT name, value FROM v$parameter WHERE name='processes'；修改需ALTER SYSTEM SET processes=500 SCOPE=SPFILE并重启，且ulimit -u必须≥新processes值。
直接改 processes 参数就行，sessions 通常不用手动设——Oracle 会按公式自动算，硬设反而容易出错。
查当前 processes 实际值别信默认文档
初始化参数文件（spfile 或 pfile）里怎么写，数据库就怎么跑。查出来的值才是真实生效的限制。
- 用
SELECT name, value FROM v$parameter WHERE name = 'processes';最准，v$parameter是运行时视图，反映实例当前配置 -
SHOW PARAMETER processes也能看，但注意它只显示已加载的参数；如果实例没正常启动，可能返回空或0 - 如果查出来
value = 0，先执行SELECT status FROM v$instance;确认实例是否已启动
ALTER SYSTEM SET processes=... 必须带 SCOPE=SPFILE 并重启
processes 是静态参数，不能动态修改。写进内存（SCOPE=MEMORY）无效，写进 spfile 才是真改。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 正确命令：
ALTER SYSTEM SET processes = 500 SCOPE=SPFILE; - 错误操作：
SCOPE=BOTH或SCOPE=MEMORY—— 执行成功但重启后还原 - 改完必须执行：
SHUTDOWN IMMEDIATE再STARTUP；ALTER SYSTEM RELOAD对这个参数完全没用
重启失败？立刻检查 ulimit -u
Linux 用户级最大进程数（ulimit -u）必须 ≥ 新的 processes 值，否则 Oracle 实例根本起不来。
- 查当前限制：
ulimit -u - 临时调高：
ulimit -u 65536 - 永久生效需改
/etc/security/limits.conf，加两行：* soft noproc 65536* hard noproc 65536 - 改完还需确保
/etc/pam.d/login包含session required /usr/lib64/security/pam_limits.so
报 ORA-00020 时别乱动 sessions
ORA-00020: maximum number of processes (%s) exceeded 表示操作系统进程资源见底，不是会话层问题。
-
sessions依赖processes：每个会话都要占一个进程槽位 - Oracle 默认按
1.5 * processes + 22（19c+）推导sessions，已预留后台进程开销 - 手动设
sessions只在一种场景合理：应用连接池明确控制活跃会话数，且确认它远低于processes限额 - 设
sessions > 1.5 * processes在旧版本可能导致共享池结构异常；19c+ 虽支持SCOPE=BOTH动态改，但前提是processes还有余量
最容易被忽略的是：改完 processes 后不检查 ulimit -u，结果重启卡在 “实例无法启动”，连错误日志都写不出来。
