必须启用resource_manager_plan，否则所有CPU限制无效；需在CDB$ROOT执行ALTER SYSTEM SET resource_manager_plan='DEFAULT_PLAN' SCOPE=BOTH，并确认DBA_RSRC_PLANS中状态为ACTIVE，否则用户始终归属OTHER_GROUPS且无任何配额。
resource_manager_plan没启用，所有CPU限制都无效
直接结论：不执行 alter system set resource_manager_plan = 'default_plan' scope=both，后续所有配置全是内存草稿，重启即丢，用户永远落在 other_groups——这个组默认无任何cpu配额。
验证是否启用：SELECT value FROM v$parameter WHERE name = 'resource_manager_plan'。返回空值或空字符串，就说明没开。必须在 CDB$ROOT 执行启用命令，且确认 DBA_RSRC_PLANS 中该 plan 状态为 ACTIVE。
常见错觉：以为改了 profile 就生效，或者建了 consumer group 就自动起作用。其实只要 plan 没启用，v$session 里看到的 consumer_group 必然是 OTHER_GROUPS，查 SELECT username, consumer_group FROM dba_users u JOIN v$session s ON u.username = s.username 就能立刻验证。
必须配齐三要素：consumer_group、plan_directive、mapping
缺一不可。漏掉任意一个，用户就 fallback 到 OTHER_GROUPS，等于没配。
-
CREATE_CONSUMER_GROUP：不能动DEFAULT_CONSUMER_GROUP，必须新建，比如'LIMITED_USER_GROUP' -
CREATE_PLAN_DIRECTIVE：必须显式指定CPU_P1（或其他 P1–P8），数值是该优先级可占 CPU 百分比上限，不是保证值；未用完部分会下放给低一级 -
SET_CONSUMER_GROUP_MAPPING：把ORACLE_USER映射到目标组，且必须调用SET_CONSUMER_GROUP_MAPPING_PRI(oracle_user => 1)设优先级，否则可能被service_name或client_id覆盖
所有操作前要 CREATE_PENDING_AREA()，提交时必须 SUBMIT_PENDING_AREA()，否则全是内存草稿。
CPU_PER_SESSION 和 CPU_PER_CALL 单位是“十分之一秒”，不是秒
比如设 CPU_PER_SESSION => 3600，实际是 360 秒（3600 × 0.1s），不是 3600 秒；CPU_PER_CALL => 200 是 20 秒。
这两个参数在 12c+ 已废弃于 profile，仅当它们出现在 CREATE_PLAN_DIRECTIVE 的参数列表中、且资源管理器已启用时才生效。单独执行 ALTER PROFILE default LIMIT CPU_PER_SESSION 3600 完全无效。
超限行为不同：CPU_PER_CALL 触发 ORA-02392，语句中断；CPU_PER_SESSION 触发 ORA-02393，整个会话断开。二者不叠加，谁先到谁先报错。
用户没授权就切不进 consumer group
即使映射和指令都配好了，用户仍无法进入目标组——因为 Oracle 默认禁止用户自行切换 consumer group。
必须显式授权：DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP('target_user', 'LIMITED_USER_GROUP', FALSE)。如果想批量授权，可授给 PUBLIC，但生产环境慎用。
验证方式：登录目标用户后执行 SELECT sys_context('USERENV', 'CONSUMER_GROUP') FROM dual，返回值应与你配置的组名一致；再查 v$session 确认 consumer_group 字段是否更新。
真正容易被忽略的点是：CDB$ROOT 中启用 plan 后，PDB 内用户是否受控，取决于该 PDB 是否继承了 plan（DEFAULT_PLAN 支持继承，自定义 plan 需显式加 PDB_DIRECTIVE）。别只在 CDB 配，忘了检查 PDB 上的实际生效状态。
