AWR Warehouse 在 Oracle 19c 中需手动部署 EMCC 13.5+/24.1+ 作为管理中枢，依赖独立仓库数据库（12.1.0.2+，SYSAUX≥50GB），不支持直接 SQL 调用；必须配置 DB Link/JDBC、权限及保留策略，并通过 EMCC 进行数据清理与跨库对比分析。
Oracle 19c 中 AWR Warehouse 不是开箱即用的功能，必须手动部署并配置 Enterprise Manager Cloud Control（EMCC）作为管理中枢；直接在数据库里执行 SQL 或调用 DBMS_WORKLOAD_REPOSITORY 无法启用它。
AWR Warehouse 必须依赖 EMCC 13.5+ 或 24.1+
AWR Warehouse 的核心是独立的「仓库数据库」+「EMCC 采集服务」，不是数据库内置组件。你不能像生成本地 AWR 报告那样用 @?/rdbms/admin/awrrpt.sql 或 DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML 调出来。
- 仓库数据库必须是 Oracle 12.1.0.2+（推荐 19c），且需单独安装、打补丁、配置 SYSAUX 空间充足（通常需 50GB+ 起）
- EMCC 必须是 13.5.0.17 或 24.1.0.0 及以上版本，低版本不支持 19c 源库的 AWR 数据抽取
- 源数据库（被监控的 19c 实例）必须开启
STATISTICS_LEVEL = TYPICAL或ALL，且CONTROL_MANAGEMENT_PACK_ACCESS不能为NONE - EMCC 和仓库数据库之间需配置 DB Link 或 JDBC 连接，并授予
SELECT_CATALOG_ROLE和EM_EXPRESS_ALL权限
SYSAUX 空间暴涨是常见失败点
AWR Warehouse 启动后，默认会把所有源库的 WRH$ 历史表同步到仓库数据库的 SYSAUX 表空间中。若未限制保留策略或未清理旧数据，WRI$_SQLSET_PLAN_LINES、WRI$_OPTSTAT_HISTGRM_HISTORY 等 LOB 表会迅速吃满 SYSAUX。
- 运行
SELECT occupant_name, ROUND(space_usage_kbytes/1024/1024, 2) AS gb FROM v$sysaux_occupants ORDER BY space_usage_kbytes DESC查看占用大户 - 重点关注
SM/ADVISOR（含 SQL Tuning Set）、OPTIMIZER（统计信息历史）、EM（OEM 元数据残留） - 不要直接
TRUNCATE TABLE或DROP，应通过 EMCC 界面的「AWR Warehouse → Purge Data」操作，或调用DBMS_AWR_WAREHOUSE.PURGE_DATA存储过程 - 仓库数据库的
dba_hist_wr_control中的retention设置（单位：分钟）要远大于源库，否则同步失败：例如源库设为 1440 分钟（1 天），仓库建议设为 43200（30 天）
跨库性能对比必须用 EMCC 的「Compare Periods」功能
AWR Warehouse 的价值在于横向分析——比如比对生产库 A 和 B 在相同业务周期内的 db file sequential read 等待事件趋势。这个能力不在 SQL 层，只在 EMCC 图形界面提供。
- 登录 EMCC → Targets → AWR Warehouse → «Compare Periods»
- 选择两个及以上源数据库目标，指定时间范围（必须落在各源库的 AWR 快照窗口内）
- EMCC 自动拉取各库对应时段的
WRH$_SYSTEM_EVENT、WRH$_SQLSTAT等视图数据，在仓库中做归一化聚合 - 若发现某库的
log file sync平均等待时间显著高于其他库，说明其 Redo 日志写入链路（如存储延迟、LGWR 配置）存在差异，而非 SQL 问题 - 导出对比结果为 PDF 或 CSV 时，注意字段名带前缀（如
DB_A_WRH$_SYSTEM_EVENT.TIME_WAITED_MICRO），避免直接用脚本解析时字段冲突
真正难的是权限链和空间配额的闭环控制：EMCC 用户要有源库的 SELECT ANY DICTIONARY 权限、仓库库的 INSERT/UPDATE 权限、以及操作系统层对 emagent 进程的磁盘写入限额。任何一个环节断掉，AWR 数据就卡在「Extract」阶段不动，而日志里只报模糊的 ORA-06512 错误，不会告诉你缺的是哪个 grant。
