@awrrpt.sql仅生成html/text报告，不导出原始awr数据；需用@awrextr.sql提取、@awrload.sql导入，且须验证快照存在性、statistics_level及归档模式，确保directory权限、bid/eid连续、sysaux空间充足，并严格匹配源目库dbid。
awrrpt.sql 只生成报告，不导出原始数据
很多人误以为 @awrrpt.sql 能把 AWR 原始快照数据打包带走——它只生成 HTML 或 TEXT 报告，所有统计值都是实时计算的，不包含底层 DBA_HIST_* 表数据。想离线分析，必须用 @awrextr.sql 提取二进制 dump 文件，再用 @awrload.sql 导入目标库。
运行 awrextr.sql 前必须验证三件事
跳过任一检查，@awrextr.sql 很可能静默失败或导出空文件：
-
SELECT MIN(snap_id), MAX(snap_id) FROM dba_hist_snapshot WHERE end_interval_time > SYSDATE - 7;—— 若无结果，说明最近 7 天没快照，先查dba_hist_wr_control确认 retention 和 interval 是否被设为 0 -
SHOW PARAMETER statistics_level;—— 必须是TYPICAL或ALL；BASIC会停掉所有 AWR 采集 -
ARCHIVE LOG LIST;—— 非 ARCHIVELOG 模式下，@awrextr.sql在打包阶段卡死并报ORA-13504
awrextr.sql 的三个关键参数怎么填才不丢数据
directory_name、bid、eid 是最易填错的参数，错误不会立刻报错，而是导致部分表缺失或 dump 文件体积异常小：
-
directory_name必须是数据库内已创建的 DIRECTORY 对象（不是 OS 路径），且执行用户有READ和WRITE权限：GRANT READ, WRITE ON DIRECTORY my_awr_dir TO your_user; -
bid和eid必须是连续快照 ID —— 中间不能有缺失或重启断点，否则DBMS_SWRF_INTERNAL.AWR_EXTRACT会跳过整段 - 别用“最近 24 小时”这种模糊描述，先查
SELECT snap_id, begin_interval_time FROM dba_hist_snapshot ORDER BY snap_id DESC FETCH FIRST 10 ROWS ONLY;拿到确切 ID 再传参
awrload.sql 导入时 SYSAUX 表空间容易撑爆
导入 dump 文件前，目标库的 SYSAUX 表空间至少要预留 2–3 倍 dump 文件大小的空间。AWR 数据在导入时会重建索引、物化视图和统计信息，临时膨胀很常见：
- 导入前执行：
SELECT tablespace_name, used_space * 8192 / 1024/1024 AS mb_used FROM v$tablespace ts JOIN v$sysaux_occupants o ON ts.ts# = o.tablespace_id WHERE o.occupant_name = 'AWR'; - 如果目标库已有旧 AWR 数据，建议先清空：
EXEC DBMS_WORKLOAD_REPOSITORY.drop_snapshot_range(low_snap_id => 1, high_snap_id => 999999); - 导入命令示例：
@?/rdbms/admin/awrload.sql，按提示输入 dump 文件名、schema 名（通常SYSAUX）、以及目标库的DBID（必须和源库一致，否则无法关联历史）
实际操作中最容易忽略的是：源库和目标库的 DBID 必须相同，否则即使导入成功，awrrpt.sql 在目标库运行时也查不到任何快照数据——因为 AWR 视图默认过滤本库 DBID。
