_awrextr.sql导出awr数据前必须确认三件事：1. dba_hist_snapshot中有有效快照；2. 执行用户具备select_catalog_role及sysaux表空间read权限；3. 数据库处于archivelog模式。
_awrextr.sql 不是“指定时间段就能导出”，它只认 snap_id，且严格依赖源库的快照连续性、权限配置和归档模式。直接运行大概率失败或导出空数据。
检查 DBA_HIST_SNAPSHOT 是否有可用快照
没快照，_awrextr.sql 就无数据可导。别跳过这步——很多报错（比如导出后文件为空、ORA-13504）都源于此。
- 执行
SELECT MIN(snap_id), MAX(snap_id) FROM dba_hist_snapshot WHERE end_interval_time > SYSDATE - 7;确认最近 7 天有快照 - 若无结果，查
SELECT * FROM dba_hist_wr_control;看保留天数和采样间隔是否被调成 0 或禁用 - 再查
SHOW PARAMETER statistics_level;，值必须是TYPICAL或ALL；BASIC会停掉 AWR 采集
确认执行用户权限与数据库归档模式
_awrextr.sql 在后台调用 DBMS_SWRF_INTERNAL.AWR_EXTRACT，这个包对权限和环境极其敏感。
- 用户必须有
SELECT_CATALOG_ROLE角色（不是仅SELECT权限） - 用户必须对
SYSAUX表空间有READ权限（GRANT READ ON TABLESPACE sysaux TO username;） - 数据库必须处于
ARCHIVELOG模式：ARCHIVE LOG LIST查看；非归档模式下脚本会在打包阶段卡死并报ORA-13504
正确传参：directory_name、file_name、bid/eid
这三个参数里，directory_name 和 bid/eid 最容易填错，且错误不报明显异常，而是静默失败或丢表。
-
directory_name是 Oracle 的 DIRECTORY 对象名（如DATA_PUMP_DIR），不是 OS 路径；需提前用CREATE DIRECTORY创建，并GRANT READ, WRITE ON DIRECTORY xxx TO username; -
file_name只能是纯文件名（如awr_20260510.dmp），不能含路径；实际写入位置由 DIRECTORY 对象指向的 OS 目录决定 -
bid和eid必须是真实存在的snap_id，且bid ；若中间快照被手工清理过（比如 <code>DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE），eid不能“跳空”，否则部分历史表（如DBA_HIST_SQLSTAT）会被静默跳过
导出后验证与常见静默问题
导出完成不等于数据完整。尤其跨库迁移分析时，漏表会导致目标库 awrload.sql 导入失败或 TOP SQL 分析缺失。
- 检查导出日志末尾是否有
"Extract completed successfully"—— 仅这一句不能信，还要看前面有没有"skipping table ..." - 用
strings awr_20260510.dmp | grep -i "dba_hist_sqlstat" | head -5粗略确认关键表是否在 dump 中 - 若目标库导入时报
ORA-20100: No data found for snapshot range，大概率是源库导出时因快照断点导致DBA_HIST_SNAPSHOT本身没导全
真正麻烦的不是命令怎么输，而是 snap_id 连续性、DIRECTORY 权限粒度、以及归档模式这三处——它们不出错则一切顺利，一出错就难定位，且错误信息模糊。动手前花两分钟查清这三项，比导出失败后再翻日志快得多。
