必须在CDB$ROOT中显式启用RESOURCE_MANAGER_PLAN参数，否则所有PDB的CPU/IO/并行资源隔离全部失效；该参数需通过ALTER SYSTEM SET RESOURCE_MANAGER_PLAN='my_cdb_plan' SCOPE=BOTH在CDB$ROOT执行，RAC环境下确保各实例同步生效。
必须在cdb级别启用resource_manager_plan，否则所有pdb的cpu/io/并行资源隔离全部失效。
RESOURCE_MANAGER_PLAN 必须显式启用
Oracle 12c RAC中，CDB Resource Manager默认不激活。即使你创建了CDB_PLAN并添加了CDB_PLAN_DIRECTIVE，若未设置RESOURCE_MANAGER_PLAN参数，所有PDB仍共享全部CPU和并行服务器资源，无任何限制效果。
-
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'my_cdb_plan' SCOPE=BOTH;是强制步骤，不可跳过 - 该参数只在CDB$ROOT中生效，不能在PDB内执行
- RAC环境下需确保所有实例同步生效（
SCOPE=BOTH已覆盖SPFILE+内存） - 若使用Broker管理RAC，还需检查
srvctl是否覆盖了该参数（Broker可能重置为DEFAULT_CDB_PLAN）
shares 和 utilization_limit 的实际作用差异
shares仅在CPU争用时起调度权重作用，而utilization_limit才是硬性上限——这点常被混淆。
-
shares=3vsshares=1：当两个PDB同时满负荷运行时，前者获得约75% CPU时间，后者约25%；但若只有后者在跑，它仍可用满100% -
utilization_limit=40：无论其他PDB是否空闲，该PDB最多只能用40%的CDB总CPU，超限即被节流 - 二者可共存：
shares=2, utilization_limit=60表示“优先级更高，但绝不超60%” - RAC中
utilization_limit按整个CDB的CPU总量计算，不是单节点
IO限制（MAX_IOPS / MAX_MBPS）必须在PDB内设置
MAX_IOPS和MAX_MBPS是PDB级参数，不能在CDB$ROOT中统一设为非零值来“批量控制”，否则所有PDB都继承同一限制，失去差异化管理能力。
- 进入目标PDB后执行：
ALTER SYSTEM SET MAX_IOPS = 800 SCOPE=BOTH; - 该设置仅对该PDB生效，不影响其他PDB或CDB$ROOT
- 注意：这两个参数对LGWR、DBWR的写IO不生效，所以高redo压力场景下IO节流可能不明显
- 低于
MAX_IOPS=100或MAX_MBPS=25易导致小文件随机读写严重抖动，不建议设得过低
验证资源限制是否真实生效
别只看DBA_CDB_RSRC_PLANS里有没有记录，要查实时度量数据才能确认节流发生。
- 查当前节流状态：
SELECT * FROM V$RSRCMGRMETRIC WHERE CON_ID = <pdb_con_id>;关注CURRENT_UTILIZATION和THROTTLED列 - 查历史IO瓶颈：
SELECT IOPS, IOMBPS, AVG_IO_THROTTLE FROM DBA_HIST_RSRC_PDB_METRIC WHERE PDB_NAME = 'MY_PDB';中AVG_IO_THROTTLE > 0说明已触发IO限速 -
V$RSRC_CONSUMER_GROUP只反映CDB$ROOT的consumer group，不显示PDB内部的资源组，别误查 - 真正压测时，用
oratop或ash report观察resmgr:cpu quantum等待事件，这是CPU节流的直接证据
最容易被忽略的是：RAC中每个节点的V$RSRCMGRMETRIC只反映本节点视角的资源使用，跨节点聚合需手动关联INST_ID；且utilization_limit的百分比始终以整个CDB的CPU总量为分母，不是单机核数。
