resource manager 是 oracle 唯一能从数据库内部对单个用户或会话组进行 cpu 和 io 资源硬性调度控制的机制；profile 仅支持会话级软性限制且无法实时干预运行中语句，cpu_count 等参数只影响全局实例行为。
Resource Manager 是唯一能硬限用户 CPU/IO 的机制
PROFILE 只能做软性会话级统计，比如 CPU_PER_SESSION 是语句执行完才累加、不干预运行中 SQL；LOGICAL_READS_PER_SESSION 统计的是逻辑读块数，不是物理 IO 带宽，更不会限速。你设了 CPU_PER_SESSION = 3600，一个跑 2 小时的全表扫描照样吃满 CPU。真正能实时掐住 CPU 调度、压住 IO 吞吐的，只有 Resource Manager。
Resource Manager 三要素缺一不可
漏掉任意一个，用户就自动掉进 OTHER_GROUPS——而该组默认没配任何 CPU 或 IO 配额，等于白设：
- 先建消费者组：
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP，别直接改DEFAULT_CONSUMER_GROUP，它是系统保留组 - 再建计划指令：
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE必须显式指定CPU_P1（Level 1 百分比）和MAX_IOPS/MAX_MBPS（仅 PDB 级生效） - 最后配映射规则：
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING要用ORACLE_USER属性绑定用户名，且必须调DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING_PRI把优先级设为 1，否则可能被CLIENT_ID或SERVICE_NAME覆盖 - 所有操作前必须
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA，提交前必须DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA，否则全是内存草稿，重启即丢
PDB 环境下 IO 限值只在 PDB 级设置才生效
MAX_IOPS 和 MAX_MBPS 这两个参数，在 CDB$ROOT 里设只是作为新 PDB 的继承模板，对现有 PDB 内的用户完全无效。真实生效要满足两个硬条件：
- 目标 PDB 已启用资源管理器：查
v$parameter中resource_manager_plan是否非空；没开这个，cpu_count、pdb_memory_limit全都不起作用 - 必须在目标 PDB 内执行
CREATE_PLAN_DIRECTIVE并指定MAX_IOPS，且该 directive 所属 plan 已被 PDB 加载（比如ALTER PLUGGABLE DATABASE pdb01 SET PARAMETER resource_manager_plan = 'MY_PLAN'）
Profile 仍值得配，但只管“防误操作”而非“防恶意占用”
Profile 不是废的，它适合做基础守门员：
- 设
SESSIONS_PER_USER = 5防应用连接泄漏 - 设
IDLE_TIME = 30自动断开挂起会话 - 设
CPU_PER_CALL = 1000（10 秒）拦住单条慢 SQL，避免一条语句拖垮整个会话 - 但必须先开全局开关：
ALTER SYSTEM SET resource_limit = TRUE，否则所有 limit 参数都不生效
真正要卡死某个用户长期霸占 CPU 或打爆磁盘，Profile 没用；Resource Manager 配错一个环节，也等于没配。最常被跳过的坑是：忘了在 CDB$ROOT 开 resource_manager_plan，或者把 MAX_IOPS 写在 CDB$ROOT 里以为能管到 PDB 用户。
