AWR默认不采集PDB级数据，所谓“PDB AWR报告”实为CDB级报告误读或非标准生成，不可信；PDB无原生AWR快照，因相关基表与采集进程仅存在于CDB$ROOT。
AWR默认不采集PDB级数据，你看到的“PDB AWR报告”大概率是CDB级别报告误读或手动强制生成的非标准视图，根本不可信。
为什么PDB没有原生AWR快照
Oracle 19c中，DBA_HIST_SNAPSHOT、DBA_HIST_SYSMETRIC_SUMMARY等核心AWR表只在CDB$ROOT中存在，且所有快照数据均按CDB维度聚合。PDB本身不维护独立的WRM$_*基表，也不触发自己的快照采集任务——GATHER_STATS_JOB和MMON进程只在CDB层级运行。
常见错误现象：
- 用户用
ALTER SESSION SET CONTAINER = pdb1后执行@?/rdbms/admin/awrrpt.sql，脚本仍连接CDB$ROOT并生成CDB报告，但界面显示“PDB1”仅因当前容器名被误取 - 手动调用
DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML时传入inst_num为PDB实例号（实际不存在），导致参数错位、数据错乱 - 第三方监控工具从
V$SYSMETRIC查PDB指标，但该视图在PDB中返回的是CDB全局值，非PDB隔离数据
真能看PDB CPU消耗？只有两个合法路径
必须绕过AWR，改用实时、容器感知的动态性能视图：
-
V$RSRCPDTSTAT：唯一官方支持的PDB资源使用统计视图，含CPU_WAIT_TIME、CONSUMER_GROUP_CPU_WAITS等字段，需配合DBA_RSRC_PLANS确认资源计划是否启用 -
V$CONTAINERS+V$SYSMETRIC（CDB$ROOT中查）：通过CON_ID关联，筛选出对应PDB的METRIC_NAME IN ('CPU Usage Per Sec', 'Host CPU Utilization (%)')，但注意这是采样值，非AWR历史聚合 - 禁用
AWR_PDB_METRICS隐含参数（不推荐）：该参数在19c中默认FALSE，强行设为TRUE会引发不稳定，Oracle文档明确标注为“内部测试用途”
误把CDB报告当PDB报告时最常踩的坑
当你在CDB报告里看到“CPU异常”，实际可能是以下情况之一：
-
DB CPU高但Time Model Statistics中sql execute elapsed time占比低 → 真实瓶颈在CDB层后台任务（如ARCH进程归档、DBWn写脏块），与PDB无关 -
Top SQL列表中SQL_ID执行次数突增，但CON_ID列全为1（CDB$ROOT）→ 这些SQL来自CDB层维护作业，不是PDB应用发起 -
Load Profile中Physical Reads飙升，但Tablespace IO Stats显示SYSAUX或SYSTEM表空间IO高 → 典型CDB元数据操作（如PDB克隆、日志切换），非PDB业务负载
真正要定位PDB级CPU问题，别碰AWR报告——直接连CDB$ROOT，跑SELECT con_id, value FROM v$sysmetric WHERE metric_name = 'CPU Usage Per Sec' AND group_id = 2 AND con_id > 2，再结合V$RSRCPDTSTAT比对。AWR的“PDB报告”本质是幻觉，信它只会把排查方向彻底带偏。
