AWR 默认不支持 PDB 级别快照采集，所有快照均在 CDB$ROOT 统一生成，PDB 无独立快照机制；性能数据需通过 CON_ID 过滤 CDB 视图（如 DBA_HIST_ACTIVE_SESS_HISTORY）获取。
AWR 默认不支持 PDB 级别快照采集
oracle 12c 多租户下，dba_hist_snapshot 和底层 awr 快照始终在 cdb$root 中统一生成，pdb 没有独立的 awr_snap 进程或专属快照表空间。所谓“pdb 级别 awr”，本质是通过 cdb 视图按 pdb_id 或 con_id 过滤出归属该 pdb 的性能数据（如 dba_hist_sqlstat、dba_hist_sysmetric_history），而非物理隔离的快照。
常见错误现象：SELECT * FROM DBA_HIST_SNAPSHOT WHERE CON_ID = <pdb_con_id> 查不到记录 —— 因为 DBA_HIST_SNAPSHOT 的 CON_ID 永远是 0（CDB 层）；真正带 CON_ID 的是子视图如 DBA_HIST_ACTIVE_SESS_HISTORY。
- 必须在 CDB$ROOT 中执行 AWR 相关操作（如
DBMS_WORKLOAD_REPOSITORY调用） - PDB 内无法运行
awrrpt.sql或调用awr_report_text，会报错ORA-13541: system moving window baseline size (86400) greater than retention (7200)类似权限/上下文错误 - 所有快照间隔、保留策略、baseline 都由 CDB 统一控制，PDB 不能覆盖
如何查某个 PDB 的历史性能数据（非快照，而是快照中的 PDB 归属数据）
关键不是“生成 PDB 快照”，而是“从 CDB 的 AWR 数据中准确定位某 PDB 的指标”。核心靠 CON_ID 字段过滤，且需确认视图是否支持多租户上下文。
使用场景：排查某 PDB 响应变慢，想看它过去 1 小时的 SQL 执行时间分布、I/O 等待、内存硬解析率。
- 优先用
DBA_HIST_ACTIVE_SESS_HISTORY：含CON_ID、SQL_ID、EVENT、SESSION_STATE，粒度细（秒级采样），是定位 PDB 级等待的主力 -
DBA_HIST_SQLSTAT含CON_ID，但只存每小时聚合值；注意EXECUTIONS_DELTA是增量，需按SNAP_ID排序后做差值计算 - 避免用
V$动态视图（如V$SQL）替代 AWR —— 它们只反映当前 PDB 的内存内容，无历史纵深 - 示例：查 PDB1（
CON_ID=3）最近 2 小时最耗时的 SQL
SELECT sql_id, sum(elapsed_time_delta)/1000000/sum(executions_delta) avg_ela_sec FROM dba_hist_sqlstat s JOIN dba_hist_snapshot sn USING (snap_id) WHERE s.con_id = 3 AND sn.begin_interval_time > sysdate - 2/24 AND executions_delta > 0 GROUP BY sql_id ORDER BY avg_ela_sec DESC FETCH FIRST 5 ROWS ONLY;
为什么不能给每个 PDB 单独设 AWR 保留时间或快照频率
AWR 的底层存储（WRH$_* 表）和快照机制（WRM$_* 元数据）全部建在 CDB$ROOT 的 SYSAUX 表空间，且所有快照 ID（SNAP_ID）全局唯一。Oracle 不提供 per-PDB 的 awr_purge 或 awr_flush 接口。
参数差异：CDB 级的 awr_purge_interval、awr_retention_hours 配置对所有 PDB 生效；试图在 PDB 中执行 ALTER SYSTEM SET awr_retention_hours=... 会报 ORA-02095: specified initialization parameter cannot be modified。
- 若强行清理某 PDB 的历史数据，只能用
DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE，但它删的是整个时间范围内的所有 PDB 数据，无法指定CON_ID - 性能影响：大量 PDB（如 50+）共用同一套 AWR，
DBA_HIST_*表体积膨胀更快，查询时若漏加CON_ID过滤，全表扫描代价极高 - 兼容性风险：12.1.0.x 版本中部分
DBA_HIST_*视图（如DBA_HIST_SEG_STAT）的CON_ID字段值可能为 NULL，需先确认版本补丁级别
真正需要隔离监控时，替代方案是什么
如果业务强要求 PDB 独立采集周期、独立保留策略、独立报告路径，AWR 本身无法满足。必须切换到更轻量、可按容器部署的监控层。
- 用
ASH实时采样 + 自定义表归档：在每个 PDB 内创建CREATE TABLE pdb_ash_log AS SELECT * FROM v$active_session_history，配合DBMS_SCHEDULER每分钟导出一次，自主控制生命周期 - 启用 PDB 级
SQL Monitoring（MONITORhint 或sql_monitor_threshold参数），数据存在V$SQL_MONITOR，虽不持久但可捕获长 SQL 的完整执行树 - 第三方工具如 Prometheus + oracledb_exporter，通过连接串分别连各 PDB 抓取
V$SYSMETRIC、V$SQL等，天然隔离 - 注意：
DBMS_SQLTUNE.CREATE_SQLSET可跨 PDB 导出 SQL，但仍是 CDB 上的操作，不解决数据物理隔离问题
容易被忽略的地方：即使用了自定义 ASH 归档，V$ACTIVE_SESSION_HISTORY 本身仍受 CDB 级 _ash_size 和 _ash_disk_filter_ratio 控制，PDB 内看到的数据量上限仍取决于 CDB 全局设置。
