<p>查当前 PROCESSES 和 SESSIONS 值用 SELECT name, value FROM v$parameter WHERE name IN ('processes', 'sessions');SESSIONS 约等于 1.5 * PROCESSES + 22，需重启实例生效。</p>
查当前 PROCESSES 和 SESSIONS 值用哪条 SQL？
直接查动态性能视图最准，别信文档里写的默认值——实际值取决于初始化参数文件或 spfile 里的配置。
SELECT name, value FROM v$parameter WHERE name IN ('processes', 'sessions');-
SESSIONS是 Oracle 自动算出来的（约等于1.5 * PROCESSES + 22），但你改PROCESSES后必须重启实例才能让SESSIONS生效，不能只改一个 - 如果查出来
value是 0，说明用了隐含参数或数据库没正常启动，先检查startup状态
改 PROCESSES 参数要重启，但为什么改完还连不上？
改了参数不等于立刻生效，Oracle 对连接数的限制是硬性的：进程没起来，新连接会被直接拒绝，报错通常是 ORA-00020: maximum number of processes (%s) exceeded。
- 必须用
ALTER SYSTEM SET processes = 500 SCOPE=SPFILE;（不能用MEMORY，因为这是静态参数） - 改完要
SHUTDOWN IMMEDIATE再STARTUP，光ALTER SYSTEM RELOAD没用 - 重启后确认是否生效：
SELECT value FROM v$parameter WHERE name = 'processes';，别只看 SPFILE 里写没写对 - Linux 下还要检查系统级限制：
ulimit -u，如果它比PROCESSES小，Oracle 实例自己都起不来
应用连不上时，到底是 PROCESSES 还是 SESSIONS 卡住了？
优先看错误信息本身。Oracle 报错会明确告诉你瓶颈在哪，别猜。
- 报
ORA-00020→PROCESSES耗尽，是操作系统级进程资源不够 - 报
ORA-00018: maximum number of sessions exceeded→SESSIONS耗尽，一般是应用没正确释放连接（比如连接池配置过大、没 close） -
v$session里查status = 'INACTIVE'且logon_time很老的会话，大概率是泄漏；v$process行数接近PROCESSES值，就该扩容了 - 注意：RAC 环境下每个节点独立计算
PROCESSES，别拿总连接数去比单节点参数
调整后连接数还是上不去，可能漏了什么？
Oracle 的连接控制是多层的，参数只是其中一环，常被忽略的是监听器和客户端配置。
- 检查
listener.ora里的MAX_PROCESSES（如果有），它会拦截连接请求早于 Oracle 实例判断 - JDBC 连接串加了
connectionProperties=oracle.jdbc.maxCachedBufferSize=0这类参数？某些驱动版本会在客户端缓存连接，导致服务端看到的活跃会话数虚高 - DBA 可能开了资源管理器（Resource Manager），在
PLAN里限制了某个用户/组的并发会话数，查dba_rsrc_consumer_group_privs - 如果用的是共享服务器模式（Shared Server），
PROCESSES控制的是 dispatcher 和 shared server 进程数，不是用户连接数，此时要看shared_servers和max_shared_servers
改参数本身不难，难的是确认每一层有没有卡住——从监听器、OS 限制、实例参数，到应用行为和资源计划，漏掉一层，调了也白调。
