awrextr.sql不导出性能基线，仅导出指定快照ID范围的AWR原始数据；基线需手动查询DBA_HIST_BASELINE获取start_snap_id和end_snap_id，并在脚本中精确输入，导入后须用DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE重建。
awrextr.sql 不导出“性能基线”，它只导出快照（snap_id 范围）对应的原始 AWR 数据。基线（baseline）是逻辑标记，不是独立物理数据——导出时不会打包 DBA_HIST_BASELINE 表本身，也不会自动包含基线所覆盖的快照范围。想把基线一起迁移，必须手动确认并指定其对应的 start_snap_id 和 end_snap_id。
查基线对应的快照范围再传给 awrextr.sql
基线信息存在 DBA_HIST_BASELINE，但它的快照边界只是元数据。你得先查清实际要导的数据区间：
- 运行
SELECT baseline_name, start_snap_id, end_snap_id, dbid FROM dba_hist_baseline WHERE baseline_name = 'YOUR_BASELINE_NAME'; - 确认这些
snap_id在DBA_HIST_SNAPSHOT中真实存在且状态正常：SELECT snap_id, begin_interval_time, status FROM dba_hist_snapshot WHERE snap_id BETWEEN :start AND :end AND dbid = :dbid; - 如果基线跨多个
dbid（比如 RAC 多实例不同dbid），awrextr.sql一次只能处理一个dbid，得分别导出
awrextr.sql 里填 bid/eid 必须严格对应基线快照 ID
脚本交互中要求输入的 begin snapshot id 和 end snapshot id 就是上面查到的 start_snap_id 和 end_snap_id，不能填时间、不能填基线名，也不能靠估算——填错一个数字，就可能漏掉关键快照或引入不连续数据。
- 例如基线
'Nightly_Batch'对应start_snap_id = 1024、end_snap_id = 1056，那就直接输1024和1056 - 别试图用
SELECT MIN(snap_id)...动态算——基线定义后快照可能被删，动态查到的范围和基线实际覆盖的不一致 -
awrextr.sql不校验你输的bid/eid是否构成合法基线，只按快照 ID 拉表数据；导完后基线记录本身不会出现在目标库
导入后需手动重建基线，不能依赖导出包
awrload.sql 加载完数据后，DBA_HIST_BASELINE 表仍是空的。目标库上必须显式执行 DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE 才能恢复基线语义：
- 连接目标库，用源库查到的相同
start_snap_id、end_snap_id和baseline_name再建一次：EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(1024, 1056, 'Nightly_Batch'); - 注意目标库
dbid必须和源库一致，否则CREATE_BASELINE会报ORA-13516；若不一致，得先用DBMS_SWRF_INTERNAL.REGISTER_DATABASE注册源库dbid - 基线名称允许重复，但同一
dbid下不能有重叠时间范围的同名基线，否则报ORA-13521
容易被忽略的权限与归档模式硬性依赖
哪怕快照 ID 完全正确，awrextr.sql 仍可能静默失败或导出空包，根源常在环境配置：
- 执行用户必须有
SELECT_CATALOG_ROLE（仅SELECT权限不够），且对SYSAUX表空间有READ权限：GRANT READ ON TABLESPACE sysaux TO your_user; - 数据库必须为
ARCHIVELOG模式：ARCHIVE LOG LIST查看；非归档下脚本会在打包阶段卡住并最终报ORA-13504 -
statistics_level必须是TYPICAL或ALL；设成BASIC会导致DBA_HIST_SNAPSHOT无新数据，基线范围内的快照根本不存在
