直接看resmgr:cpu quantum等待事件是否高频出现——这是resource manager主动掐断会话cpu时间片的信号；若其排进top 5 timed foreground events前三且db cpu占比>60%，即坐实限流而非硬件瓶颈；再查resource limit statistics中cpu_wait_time等列是否持续近100%，并结合v$rsrc_session_info确认current_consumer_group是否为other_groups及wait_time非零。
AWR报告里哪几个地方能确认Resource Manager在限流
直接看resmgr:cpu quantum等待事件是否高频出现——这是Resource Manager主动掐断会话CPU时间片的信号。它不是硬件瓶颈，而是调度器在“排队叫号”。如果这个事件排进Top 5 Timed Foreground Events前三，且DB CPU占比同步偏高（>60%），基本坐实是Resource Manager在干预，不是CPU真不够用。
接着翻到报告末尾的Resource Limit Statistics小节（不是每个AWR默认显示，需手动展开或生成时勾选“Resource Manager”选项）。重点关注三列：CPU_WAIT_TIME、ACTIVE_SESSIONS_LIMIT、PARALLEL_EXECUTION_SERVERS_LIMIT。只要其中任一列持续接近100%，就说明对应资源被硬性卡死。
别只盯着Top SQL：SQL执行忽快忽慢、同一语句在不同时间点执行计划不变但耗时翻倍，也是典型限流表现——Resource Manager不改执行计划，只掐执行节奏。
为什么V$RSRC_SESSION_INFO比AWR更及时
AWR快照默认每小时一次，而Resource Manager的限流可能发生在分钟级甚至秒级。想实时抓现行，得查动态视图：V$RSRC_SESSION_INFO。
执行SELECT * FROM V$RSRC_SESSION_INFO WHERE CON_ID = <your_pdb_con_id>;</your_pdb_con_id>，重点看两个字段：
-
CURRENT_CONSUMER_GROUP：是不是掉进了OTHER_GROUPS？如果是，说明该PDB没被显式分配资源计划，正在吃默认的1% CPU配额 -
WAIT_TIME：非零值表示当前会话正在Resource Manager队列里排队，数值越大，等得越久
注意：V$RSRC_SESSION_INFO只反映当前瞬间状态，要连续查几次才能判断是否稳定处于等待态；而DBA_HIST_RSRC_CONSUMER_GROUP存的是历史快照，适合和AWR联动分析趋势。
PDB被塞进OTHER_GROUPS的三个确认动作
Oracle 12c+默认启用DEFAULT_PLAN，但它对PDB极不友好——所有未显式绑定资源计划的PDB，自动归入OTHER_GROUPS。这不是配置遗漏，是设计如此。
确认是否中招，按顺序做三件事：
- 查PDB的
CON_ID：SELECT CON_ID, NAME FROM V$PDBS WHERE NAME = 'YOUR_PDB'; - 查CDB$ROOT中该PDB是否绑定了专属计划：
SELECT PLAN_NAME, CONSUMER_GROUP FROM DBA_RSRC_PLANS WHERE PLAN_NAME LIKE '%YOUR_PDB%'; - 查映射规则是否生效：
SELECT ATTRIBUTE, VALUE, CONSUMER_GROUP FROM DBA_RSRC_GROUP_MAPPINGS WHERE ATTRIBUTE = 'SERVICE_NAME' AND VALUE = 'your_pdb_service';（若用用户名映射，把SERVICE_NAME换成ORACLE_USER）
漏掉任意一步，用户会话就滑进OTHER_GROUPS——它不报错、不告警，只默默让SQL变慢。
给PDB单独配资源计划时不踩坑的关键点
核心原则：不要动CDB层的DEFAULT_PLAN，而是为每个PDB建独立plan+group+mapping，在CDB$ROOT里操作。
实操必须满足四个条件：
- 调用
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA()开头，DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA()收尾，中间所有CREATE_*操作才落地 -
CREATE_PLAN_DIRECTIVE里必须显式指定MGMT_P1（比如设为80），不能只设MGMT_P2或MGMT_P3——Oracle按Level 1→2→3降序匹配，Level 1为空就跳过整个directive - PDB环境下限制IO必须用
MAX_IOPS或MAX_MBPS，且这两个参数只在PDB自己的plan directive里设置才生效；CDB$ROOT里设了只是新PDB的默认值 - 映射优先级必须设：
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING_PRI，否则ORACLE_USER可能被CLIENT_ID覆盖，导致用户没进预期组
最常被忽略的是PENDING_AREA机制——所有操作都在内存草稿区，忘了SUBMIT_PENDING_AREA，等于什么都没干。
