必须启用resource_manager_plan，否则所有用户级cpu百分比限制无效；profile中cpu_per_session已废弃，需通过资源管理器的消费者组、计划指令和映射三要素配置并激活才能生效。
必须启用 resource_manager_plan，否则所有用户级 cpu 百分比限制都无效——这是 90% 的人卡住的第一步。
为什么 PROFILE 里的 CPU_PER_SESSION 不起作用
PROFILE 中的 CPU_PER_SESSION 和 CPU_PER_CALL 在 Oracle 12c+ 已废弃，仅保留字段兼容性，实际不触发任何限流。它们单位是“十分之一秒”（如值 200 = 20 秒），但前提是：该用户必须被映射到一个明确配置了 CPU_P1 等指令的 CONSUMER_GROUP，且整个资源管理器已启用。单纯执行 ALTER PROFILE default LIMIT CPU_PER_SESSION 3600，等于没配。
- 错误现象：用户跑大查询仍占满 CPU，
v$session显示consumergroup是OTHER_GROUPS - 根本原因：没建组、没设映射、没启用 plan，用户自动 fallback 到无配额的默认组
- 验证方式：查
SELECT username, consumer_group FROM dba_users u JOIN v$session s ON u.username = s.username WHERE s.username = 'YOUR_USER'，确认是否真落到目标组
RESOURCE_MANAGER 必须配齐三要素才生效
缺一不可：CONSUMER_GROUP、PLAN_DIRECTIVE（含 CPU_P1）、SET_CONSUMER_GROUP_MAPPING。漏掉任意一个，用户就归入 OTHER_GROUPS，而该组默认无 CPU 配额。
- 建组不能直接改
DEFAULT_CONSUMER_GROUP：它被系统保留，必须用DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP新建 -
CPU_P1到CPU_P8是 8 个优先级层级，数值表示该层级内可分配的 CPU 百分比上限；未用完部分会下放给低一级，不是“保证值”而是“上限值” - 映射必须显式调用
SET_CONSUMER_GROUP_MAPPING_PRI设优先级，例如oracle_user => 1，否则可能被client_id或service_name覆盖 - 所有操作前必须
CREATE_PENDING_AREA()，提交后必须SUBMIT_PENDING_AREA()，否则全是内存草稿，重启即丢
如何让 CPU 百分比真正生效
启用 resource_manager_plan 是硬门槛。CDB$ROOT 中执行：ALTER SYSTEM SET resource_manager_plan = 'DEFAULT_PLAN' SCOPE=BOTH。注意：DEFAULT_PLAN 是 Oracle 自带的、已支持用户级控制的基础计划；自定义 plan 若未显式包含 PDB_DIRECTIVE 或 GROUP_OR_SUBPLAN 指令，配了也白配。
- 验证是否激活：
SELECT plan, status FROM DBA_RSRC_PLANS WHERE status = 'ACTIVE'，且SELECT value FROM v$parameter WHERE name = 'resource_manager_plan'返回非空值 - 用户需有切换权限：
DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP('your_user', 'YOUR_GROUP', FALSE) - 并行查询（PX）会累加 coordinator + 所有 slave 进程的 CPU 时间，但
CPU_PER_CALL只检查 coordinator 单次调用，容易误判为“没限住” - DBA 用户（如
SYS、SYSTEM）即使映射到受限组，Oracle 也会跳过资源限制——这是硬编码行为，无法关闭
最容易被忽略的是：所有配置做完后，不检查当前 PDB 是否继承了有效的 plan。在 CDB$ROOT 启用 DEFAULT_PLAN，不代表每个 PDB 都自动生效；如果某个 PDB 的 resource_manager_plan 参数为空，那它里面的用户照样不受限。
