如何配置AWR在PDB级别收集_12c多租户环境下的AWR快照隔离与管理-Oracle-PHP中文网

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></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（MONITOR hint 或 sql_monitor_threshold 参数），数据存在 V$SQL_MONITOR，虽不持久但可捕获长 SQL 的完整执行树
第三方工具如 Prometheus + oracledb_exporter，通过连接串分别连各 PDB 抓取 V$SYSMETRIC、V$SQL 等，天然隔离
注意：DBMS_SQLTUNE.CREATE_SQLSET 可跨 PDB 导出 SQL，但仍是 CDB 上的操作，不解决数据物理隔离问题