resource_limit参数必须设为true，否则profile中的sessions_per_user、cpu_per_session等资源限制全部无效；该参数默认为false，需执行alter system set resource_limit=true scope=both启用，且仅影响资源类限制，不影响密码策略。
RESOURCE_LIMIT参数必须设为TRUE，否则所有PROFILE限制都无效
Oracle的SESSIONS_PER_USER、CPU_PER_SESSION等限制全部不生效，根本原因几乎总是resource_limit参数为FALSE。这不是配置遗漏，而是数据库默认关闭资源限制机制。
检查当前状态：SHOW PARAMETER resource_limit。若返回FALSE，立即执行：ALTER SYSTEM SET resource_limit = TRUE SCOPE = BOTH。该命令无需重启，修改后新建会话即生效。
注意：此参数只控制资源类限制（CPU/会话/空闲时间等），对密码策略（如PASSWORD_LIFE_TIME）无影响——密码限制始终有效。
CPU_PER_SESSION只是软性累计限制，不能实时控住运行中的SQL
CPU_PER_SESSION单位是“百分之一秒”，设为360000即100秒。但它只在SQL语句执行结束后才做累计检查，不会中断正在跑的大查询。一个占用90% CPU的长事务，哪怕已超限，也会继续跑完才断开会话。
常见误判场景：
- 用户执行
SELECT /*+ PARALLEL(8) */ COUNT(*) FROM huge_table，CPU_PER_SESSION设了也没用 - 监控看到CPU持续100%，但
V$SESSION里CONSUMED_CPU_TIME没超限值——因为还没执行完，没触发检查点 -
LOGICAL_READS_PER_SESSION统计的是逻辑读块数，和磁盘IO带宽无关，也不能限制物理IO爆发
真能硬控CPU/IO的只有Resource Manager，且三要素缺一不可
要让某个用户（比如APP_USER）CPU使用率稳定压在20%以内，必须用DBMS_RESOURCE_MANAGER，且以下三步全得走完：
- 创建消费者组：
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('APP_GROUP') - 创建资源计划并绑定配额：
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(plan=>'MYPLAN', group_or_subplan=>'APP_GROUP', CPU_P1=>20) - 建立用户到组的映射：
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING('ORACLE_USER', 'APP_USER', 'APP_GROUP')
漏掉任意一步，用户都会落入OTHER_GROUPS——而这个组默认没有CPU配额，等于完全不限制。所有操作前必须调CREATE_PENDING_AREA，完成后必须SUBMIT_PENDING_AREA，否则全是内存草稿，不落地。
PDB环境下限制IO需额外注意MAX_IOPS/MAX_MBPS的生效范围
如果目标是限制用户物理IO（比如防并行扫描打爆磁盘），MAX_IOPS和MAX_MBPS这两个参数只在PDB级别设置才对用户生效。CDB$ROOT里设它们，只是作为新PDB的默认继承值，不影响现有PDB内的用户。
关键前提有二：
- 该PDB的
resource_manager_plan参数非空（即已启用资源管理器） -
CREATE_PLAN_DIRECTIVE中必须显式指定MAX_IOPS或MAX_MBPS，且group_or_subplan指向你建的消费者组
最容易被忽略的一点：Resource Manager对连接池复用的会话也生效，但PROFILE的SESSIONS_PER_USER只计活跃会话数，二者统计口径不同，混用时容易误判资源是否真的被控住了。
