Resource Manager 是 Oracle 唯一能从数据库内部对单个用户（或会话组）做 CPU 和 IO 资源硬性调度控制的机制；PROFILE 仅支持会话级软性资源限制且无法实时干预运行中语句，cpu_count 仅影响全局实例行为。
直接说结论：resource manager 是 oracle 唯一能从数据库内部对单个用户（或会话组）做 cpu 和 io 资源硬性调度控制的机制；仅靠 profile 或 cpu_count 参数无法限制单个用户的 cpu/io，它们要么不生效，要么只影响优化器或全局实例行为。
为什么 PROFILE 不能限制用户 CPU/IO
PROFILE 只能控制会话级软性资源（如 CPU_PER_SESSION、CONNECT_TIME），它依赖 SQL 执行结束后的累计统计，无法实时干预运行中语句的 CPU 占用；对 IO 更是完全无感——LOGICAL_READS_PER_SESSION 统计的是逻辑读次数，不是物理 IO 带宽，且不触发实时限流。一旦语句进入执行阶段，PROFILE 就失去控制力。
常见误操作：
- 给用户指定了
PROFILE并设置了CPU_PER_SESSION = 3600，但一个大查询仍长期霸占 100% CPU - 以为
SESSIONS_PER_USER能防 IO 泛滥，结果并行查询照样打爆磁盘
Resource Manager 必须配齐三要素才生效
缺一不可：消费者组（CONSUMER_GROUP）、资源计划（PLAN）、映射规则（SET_CONSUMER_GROUP_MAPPING）。漏掉任意一个，用户会自动落入 OTHER_GROUPS，而该组默认没有 CPU/IO 配额——等于没限制。
实操要点：
- 先建组：
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP，别用DEFAULT_CONSUMER_GROUP直接改，它被系统保留 - 再建计划指令：
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE中必须显式指定CPU_P1（Level 1 CPU 百分比）和MAX_IOPS/MAX_MBPS（仅限 PDB 环境下对组生效） - 映射要明确优先级：
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING_PRI设为oracle_user => 1，否则用户名映射可能被 client_id 或 service_name 覆盖 - 所有操作前必须调用
CREATE_PENDING_AREA，提交后必须SUBMIT_PENDING_AREA，否则全是内存草稿
PDB 环境下限制用户 IO 的真实生效条件
MAX_IOPS 和 MAX_MBPS 这两个参数**只在 PDB 级别设置才对用户 IO 生效**，且前提是该 PDB 已启用资源管理器（即 resource_manager_plan 非空）。CDB$ROOT 中设这两个值，只是作为新 PDB 的默认继承值，不直接约束现有 PDB 内的用户。
关键验证点：
- 查当前 PDB 是否激活计划：
SELECT value FROM v$parameter WHERE name = 'resource_manager_plan'—— 必须返回非空值（如DEFAULT_PLAN） - 查用户实际归属组：
SELECT resource_consumer_group FROM v$session WHERE username = 'MYUSER'，确保不是OTHER_GROUPS - 触发 IO 限流时会话等待事件是
resmgr: I/O rate limit，不是db file sequential read -
MAX_IOPS不限制 LGWR、DBWR、CKPT 进程的 IO，所以高事务量下仍可能观察到磁盘繁忙，但这不属于“用户 IO”范畴
容易被忽略的 CPU 分配层级陷阱
Resource Manager 的 CPU 分配是多级（Level）抢占式调度：CPU_P1 是最高优级配额，只有当所有 CPU_P1 组都用不满时，剩余 CPU 才按 CPU_P2 分配。如果你只给目标组设了 CPU_P2 = 30，但其他组占满 CPU_P1，那这个组实际可能拿不到任何 CPU。
安全做法：
- 把关键业务组放在
CPU_P1，限制组放CPU_P2，并确保CPU_P1总和 ≤ 100 - 避免在同一个 plan 中混用
CPU_P1和CPU_P2指令，除非你真需要这种抢占逻辑 - 测试时用
oradebug setmypid+oradebug call ksdwrt 1 "test"触发短时高负载，别等自然流量——自然负载下很难复现调度边界
真正难调的不是配参数，而是确认那个用户会话到底跑在哪个消费者组、走的是哪一级 CPU 分配路径；v$session 和 dba_rsrc_plan_directives 的字段对不上，八成是 pending area 没提交，或者映射规则被更高优先级属性覆盖了。
