awrextr.sql导出失败的三个常见原因是:1. dba_hist_snapshot中无有效快照;2. 执行用户缺少select_catalog_role角色或sysaux表空间read权限;3. 数据库未处于archivelog模式。

awrextr.sql 导出失败的三个常见原因
直接运行 @?/rdbms/admin/awrextr.sql 却导出空文件或卡死,大概率不是脚本问题,而是环境没对齐。必须确认三件事:
- 源库
DBA_HIST_SNAPSHOT里真有快照:执行SELECT MIN(snap_id), MAX(snap_id) FROM dba_hist_snapshot WHERE end_interval_time > SYSDATE - 7;,没结果就别往下走 - 用户必须同时具备
SELECT_CATALOG_ROLE角色 + 对SYSAUX表空间的READ权限(仅SELECT权限不够) - 数据库必须是
ARCHIVELOG模式:ARCHIVE LOG LIST查,非归档模式下会静默卡在DBMS_SWRF_INTERNAL.AWR_EXTRACT并报ORA-13504
directory_name 和 file_name 怎么填才不报错
awrextr.sql 要求的 directory_name 不是操作系统路径,而是 Oracle 的 DIRECTORY 对象名;file_name 也不含路径和后缀。填错不会立刻报错,而是静默失败或丢表。
- 先创建目录对象:
CREATE DIRECTORY AWR_DUMP_DIR AS '/u01/dump';,再授权:GRANT READ, WRITE ON DIRECTORY AWR_DUMP_DIR TO SYS; - 运行脚本时,
directory_name输入AWR_DUMP_DIR(大小写敏感,通常大写) -
file_name只输awr_202607这类纯名字,脚本自动加.dmp后缀;若输成awr_202607.dmp,最终会尝试打开awr_202607.dmp.dmp,报ORA-31640找不到文件 - 实际写入路径由
DIRECTORY对象指向的 OS 路径决定,和你在 SQL*Plus 里当前所在目录无关
bid/eid 必须连续,不能跳空
awrextr.sql 不接受“逻辑时间段”,只认 snap_id。如果中间快照被手工清理过(比如用 DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE),eid 不能跨断点设值,否则部分历史表(如 DBA_HIST_SQLSTAT)会被静默跳过,导出文件看似成功但数据不全。
- 查可用快照范围:
SELECT snap_id, end_interval_time FROM dba_hist_snapshot ORDER BY snap_id; - 确保
bid和eid都存在,且中间所有snap_id都未被删除(哪怕某天没采样,只要snap_id连续就行) - 若发现断点,比如
snap_id从 100 直接到 105,就只能分两次导出:bid=100, eid=100和bid=105, eid=105,不能设bid=100, eid=105
awrload.sql 导入时 DBID 必须手动重映射
导入不是简单 impdp,awrload.sql 会读取 dump 文件里的原始 DBID,并强制写入目标库的 WRM$_DATABASE_INSTANCE 表。若不干预,目标库 dba_hist_* 视图将查不到数据。
- 运行
@?/rdbms/admin/awrload.sql后,它会提示输入directory_name、file_name、schema_name(默认AWR_STAGE)等,但**不会问 DBID** - 导入完成后,必须立即执行:
EXEC DBMS_SWRF_INTERNAL.MOVE_TO_AWR(dbid => );,否则数据留在 staging schema 里,不进正式 AWR 表 - 查目标库 DBID:
SELECT dbid FROM v$database;,这个值要和MOVE_TO_AWR的参数一致 - 漏掉这步,后续跑
@?/rdbms/admin/awrrpti.sql会报ORA-01403: no data found或ORA-20103: Invalid AWR snapshot range
整个流程最易被忽略的是快照连续性检查和导入后的 MOVE_TO_AWR 显式调用——前者导致导出数据残缺,后者导致导入数据不可见,两者都不报严重错误,只静默失效。











