sessions_per_user是oracle profile中限制同一用户已认证且未断开会话总数的参数，仅统计v$session中status为active或inactive的行，不控制tcp连接、监听器队列或连接池空闲连接；必须启用resource_limit=true、显式绑定profile并防范inactive会话残留才能生效。
SESSIONS_PER_USER 是什么，它真能限制“并发连接”？
SESSIONS_PER_USER 不是限制 TCP 连接或应用层“连接池连接”，而是限制同一用户在数据库中**已认证、未断开的会话总数**（v$session 中 STATUS IN ('ACTIVE', 'INACTIVE') 的行数）。它生效于用户完成身份验证、Oracle 创建 session 的那一刻。常见误解是：设了 5 就能拦住 6 个 sqlplus 进程——但若其中 3 个卡在密码输错重试、2 个还在监听器排队，它们都不计入 SESSIONS_PER_USER 计数。
典型报错是 ORA-02391: exceeded simultaneous SESSIONS_PER_USER limit，这个错误只会在第 6 次成功登录时触发（前 5 个 session 已存在且未断开）。
必须启用 resource_limit 才能让 SESSIONS_PER_USER 生效
即使你创建了 profile 并赋给用户，RESOURCE_LIMIT 参数为 FALSE 时，所有 kernel 级资源限制（包括 SESSIONS_PER_USER）全部失效。
- 检查当前值：
SHOW PARAMETER resource_limit - 如返回
FALSE，执行：ALTER SYSTEM SET resource_limit = TRUE SCOPE = BOTH - 该参数修改后立即生效，无需重启实例
注意：SCOPE = BOTH 确保写入 spfile 和内存；如果用的是 pfile，需手动更新并重启。
为什么应用连不上，但 v$session 里看不到那么多会话？
这通常不是 SESSIONS_PER_USER 的问题，而是混淆了不同层级的“连接”：
- 连接池（如 HikariCP）维持的“空闲连接”仍占用会话槽位——哪怕应用没发 SQL，只要没调
connection.close()，Oracle 就视为一个INACTIVE会话 - 用户未显式指定 profile，实际走的是
DEFAULTprofile，而它的SESSIONS_PER_USER默认是UNLIMITED - DBA 或拥有
RESTRICTED SESSION权限的用户不受此限制，测试时误用 sysdba 账号会导致误判 - 监听器连接堆积（
lsnrctl status显示大量 WAITING）和SESSIONS_PER_USER无关，那是PROCESSES或操作系统 socket 限制的问题
如何验证设置是否真正起作用？
别只查 profile 定义，要观察运行时行为：
- 确认 profile 已绑定：
SELECT PROFILE FROM DBA_USERS WHERE USERNAME = 'APP_USER' - 查 profile 实际值：
SELECT LIMIT FROM DBA_PROFILES WHERE PROFILE = 'APP_USER_PROF' AND RESOURCE_NAME = 'SESSIONS_PER_USER' - 查当前会话数：
SELECT COUNT(*) FROM v$session WHERE USERNAME = 'APP_USER' - 用相同账号连续登录测试（避免用不同终端导致用户名大小写/空格差异）：
sqlplus app_user/pass@db成功后，立刻再开一个终端执行同样命令，看是否报ORA-02391
最容易被忽略的一点：已有会话不会被终止或踢出，限制只对新登录生效；如果旧会话长期不关闭（比如应用异常退出没 cleanup），配额会持续被占满，新请求就永远进不来。
