Resource Manager 是唯一能实时限制用户 CPU 的机制，通过消费者组、资源计划和映射规则动态调度 CPU 时间片，三者缺一不可；需按步骤创建待定区、组、计划指令、映射并提交，且须设置用户名映射优先级为最高，PDB 中还需单独启用 resource_manager_plan 才生效。
RESOURCE_MANAGER 是唯一能硬性限制用户 CPU 的机制
PROFILE 中的 CPU_PER_SESSION 只是会话结束后的累计统计，无法中断正在执行的 SQL；cpu_count 是实例级参数，对单个用户完全无效。真正能实时压制用户 CPU 占用的，只有 Resource Manager。它通过消费者组（Consumer Group）+ 资源计划（Plan）+ 映射规则（Mapping）三件套，在语句执行过程中动态调度 CPU 时间片。
必须配齐三要素，缺一不可
漏掉任意一个环节，用户会自动落入 OTHER_GROUPS，而该组默认没有 CPU 配额——等于没限制。
- 先调用
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA开启待定区，所有配置都在内存中暂存 - 用
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP新建组（别直接改DEFAULT_CONSUMER_GROUP） - 用
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE绑定组与计划，并显式指定CPU_P1（Level 1 百分比），例如CPU_P1 => 20表示最多占 Level 1 总 CPU 的 20% - 用
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING把用户名映射到该组，attribute => 'ORACLE_USER' - 最后必须
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA提交，否则全是草稿
映射优先级不设好，用户根本进不了目标组
Resource Manager 支持按 ORACLE_USER、CLIENT_ID、SERVICE_NAME 等多属性映射，但只生效最高优先级的一条。如果没显式设置优先级，CLIENT_ID 或服务名可能覆盖用户名映射，导致限制失效。
- 执行
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING_PRI - 把
oracle_user设为1（数值越小优先级越高），确保用户名映射优先生效 - 验证：查
SELECT * FROM DBA_RSRC_SESSION_INFO WHERE SESSION_ID = SYS_CONTEXT('USERENV','SID')，确认CONSUMER_GROUP字段值是你设的组名
PDB 环境下 CPU 限制才真正可控
在 CDB$ROOT 中配置资源计划，只影响新创建的 PDB 默认行为；现有 PDB 必须单独启用资源管理器（即 resource_manager_plan 参数非空），用户 CPU 限制才会落地。更关键的是：Resource Manager 的 CPU 控制粒度依赖于底层 OS 的调度能力，Oracle 不保证 100% 精确压制——它做的是“尽力而为”的时间片分配，而非操作系统级的 CPU cgroup 隔离。
