Oracle PROFILE 的 cpu_per_session 和 cpu_per_call 仅在 RESOURCE_LIMIT=TRUE 时生效；前者限制会话累计CPU时间（百分之一秒），超限报ORA-02392并断连，后者限制单次调用CPU时间，超限报ORA-02393但会话继续。
Oracle PROFILE 中 cpu_per_session 和 cpu_per_call 怎么设才有效
这两个参数只在 resource_limit = true 开启时起作用，否则完全被忽略。很多 dba 配了 profile 却发现 cpu 限制没生效，第一反应是参数写错了，其实八成是忘了开这个开关。
实操建议：
-
ALTER SYSTEM SET RESOURCE_LIMIT = TRUE;必须执行，且需重启实例或至少 reload spfile（部分版本支持动态生效，但稳妥起见建议确认V$PARAMETER中值为TRUE） -
cpu_per_session是整个会话生命周期内累计的 CPU 时间（单位：百分之一秒），超限后会话直接报错ORA-02392: exceeded session limit on CPU usage，连接断开 -
cpu_per_call是单次调用（比如一条SELECT、INSERT或 PL/SQL 过程执行）允许的最大 CPU 时间，超限报ORA-02393: exceeded call limit on CPU usage，当前语句失败但会话可继续 - 注意：它们计量的是「CPU 时间」，不是 Wall Clock 时间，所以高并发下不等于“卡死”或“变慢”，而是真正在 CPU 上跑的时间总和
logical_reads_per_session 和 logical_reads_per_call 的真实约束力
这两个参数控制逻辑读（buffer gets）上限，但容易误以为能防住全表扫描——其实不能。只要单次 SQL 的逻辑读没超 logical_reads_per_call，哪怕扫了 10 亿行也照常执行；而 logical_reads_per_session 是会话级累计值，对长连接、频繁查询的用户更敏感。
常见错误现象：
- 用户执行一个大查询，返回前就报
ORA-02391: exceeded simultaneous SESSIONS_PER_USER limit？不对，那是会话数限制，和逻辑读无关；真正报错是ORA-02392（CPU）或ORA-02393（call 级资源），逻辑读超限实际触发的是ORA-02394（exceeded session limit on logical reads）或ORA-02395（call limit） - 设置了
logical_reads_per_session = 10000，但用户连着跑 5 条各读 2000 块的 SQL 就挂了——因为 buffer gets 累计算，不是按语句清零 - 索引范围扫描 + 多层嵌套循环可能逻辑读远高于全表扫描，别光盯着 “全表扫描” 想当然
PROFILE 资源限制对后台作业和 SYS 用户是否生效
默认不生效。Oracle 明确文档写明：SYS 用户、以及通过 DBMS_SCHEDULER 或 DBMS_JOB 启动的作业，其会话不会应用 PROFILE 中的资源限制，除非显式指定 SET ROLE 并切换到普通用户上下文。
使用场景：
- 想限制 ETL 作业的资源消耗？别只靠 PROFILE，得在 job 创建时用
job_class绑定 resource consumer group，或者用DBMS_RESOURCE_MANAGER更细粒度控 - 应用连接池用
SYSDBA连接？PROFILE 完全无效，必须降权为普通用户再测试 - 检查是否生效：查
V$SESSION的RESOURCE_CONSUMER_GROUP列，如果是DEFAULT_CONSUMER_GROUP且没配 Resource Manager，则 PROFILE 才是唯一生效机制
为什么 ALTER PROFILE … LIMIT 后用户没立刻受限
因为 PROFILE 修改只影响新建立的会话。已存在的连接仍沿用旧限制，直到下次重连。这是最常被忽略的一点，导致 DBA 改完配置等半天，看监控没变化就怀疑配置错了。
实操建议：
- 改完 PROFILE 后，让目标用户主动断开重连，或杀掉其会话：
ALTER SYSTEM KILL SESSION 'sid,serial#'; - 验证是否生效：登录目标用户，查
SELECT LIMIT FROM DBA_PROFILES WHERE PROFILE='YOUR_PROFILE' AND RESOURCE_NAME IN ('CPU_PER_SESSION','LOGICAL_READS_PER_SESSION'); - 不要依赖
SHOW PARAMETER或V$PARAMETER，PROFILE 参数不在那里，得查数据字典视图
PROFILE 的资源限制是粗粒度、会话级的守门员，不是实时流控器。它挡不住短平快的暴力查询，也管不了已经跑起来的长事务。真要控资源，得配合 Resource Manager + SQL Monitoring + 自定义审计逻辑。
