awr快照导出失败主因是expdp不兼容11g私有类型与复杂结构，应改用flashback_scn+content=data_only逐表抽取；导入后需启用awr功能、校验平台一致性、重建xmltype列，并注意12c+语义差异导致指标漂移。
awr快照导出失败，先看expdp是否支持11g awr schema
oracle 11g 的 awr 数据存储在 sysaux 表空间中，由 dba_hist_* 系列视图暴露，底层表属于 system 和 sysaux 拥有者，且大量使用 oracle 私有数据类型（如 anydata、xmltype、rowid 变体）。直接用 expdp 导出整个 awr schema 几乎必然失败——不是权限问题，而是 data pump 本身对 awr 对象的元数据结构识别能力有限。
常见错误现象包括：
ORA-39126: Worker unexpected fatal error in KUPW$WORKER.PUT_DDLSORA-06502: PL/SQL: numeric or value error: host bind array too small- 导出日志中反复出现
skipping table "SYS"."WRH$_ACTIVE_SESSION_HISTORY"但不报错
根本原因：11g 的 AWR 表含大量压缩 LOB、虚拟列、隐藏列及分区子句，expdp 默认不启用兼容模式时会跳过或误解析这些结构。
实操建议：
- 不要用
SCHEMAS=SYS或INCLUDE=TABLE:"LIKE 'WRH\$%'"直接导出； - 改用
FLASHBACK_SCN+CONTENT=DATA_ONLY配合QUERY参数逐表抽取关键历史数据（如WRH$_SQLSTAT,WRH$_SYSTEM_EVENT）； - 必须指定
VERSION=11.2.0.4（即使源库是 11.2.0.3），否则目标端 12c+ 的impdp无法识别 11g AWR 字典版本； - 导出前执行
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT确保快照已固化，避免导出过程中被自动清理。
dump文件能导入，但AWR数据查不到——检查目标库是否启用AWR功能
很多团队把 dump 文件成功 impdp 到新库后，发现 DBA_HIST_SQLSTAT 为空，或 SELECT * FROM DBA_HIST_SNAPSHOT 返回 0 行。这不是导入失败，而是目标库压根没激活 AWR 功能。
Oracle 标准版（Standard Edition）默认禁用 AWR，仅企业版（Enterprise Edition）授权后才可启用。即使你用了企业版授权，也需手动开启：
- 确认
STATISTICS_LEVEL=TYPICAL或ALL（BASIC会彻底关闭 AWR 采集）； - 运行
EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention => 43200 )（单位分钟，即 30 天）； - 检查
V$DATABASE中PLATFORM_NAME是否与源库一致——跨平台（如 Linux → Windows）导入 AWR dump 后，部分历史统计字段（如TIME_WAITED）可能因时钟精度差异被置为 NULL，导致视图过滤失效； - 特别注意：
DBA_HIST_*视图依赖WRM$_*基础表，而这些表的OWNER是SYSAUX，不是SYS；若导入时指定了REMAP_SCHEMA=SYS:MYUSER，会导致视图失效。
从11g导出的AWR dump，在12c/19c上导入后执行计划异常
AWR 数据本身不包含执行计划，但 DBA_HIST_SQL_PLAN 表中存储的是 OTHER_XML 类型的压缩 XML 片段。11g 使用的是旧版 XML 序列化格式，而 12c+ 默认启用 XMLTYPE 存储优化（STORE AS SECUREFILE BINARY XML）。当 dump 文件导入后，若未显式重建该表的 XMLType 列，查询 DBA_HIST_SQL_PLAN.OTHER_XML 会返回空或乱码。
典型表现：
-
SELECT EXTRACTVALUE(OTHER_XML, '/other_xml/info[@type="plan_hash"]') FROM DBA_HIST_SQL_PLAN返回 NULL； -
SELECT DBMS_XPLAN.DISPLAY_AWR('sql_id', plan_hash_value)报ORA-19279: XPTY0004；
实操建议：
- 导入完成后，立即执行：
ALTER TABLE WRH$_SQL_PLAN MODIFY OTHER_XML XMLTYPE STORE AS SECUREFILE BINARY XML； - 重建相关索引：
CREATE INDEX WRH$_SQL_PLAN_IDX ON WRH$_SQL_PLAN(DBID, SQL_ID, PLAN_HASH_VALUE) COMPRESS 2； - 避免使用
DBMS_XPLAN.DISPLAY_AWR直接解析，改用SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR(...))并加FORMAT=>'BASIC +PEEKED_BINDS'显式控制解析路径。
真正卡住的不是dump兼容性，而是AWR语义迁移成本
即便 dump 成功导入、视图可查、执行计划能解析，你仍会发现：原 11g AWR 报告里的 DB Time、Hard Parse %、Buffer Gets Per Exec 等指标，在新库上数值漂移严重。这不是 bug，而是 Oracle 在 12c 引入了新的等待事件分类（如 resmgr:cpu quantum）、重写了 DBA_HIST_SYSMETRIC_SUMMARY 的聚合逻辑，并将部分采样频率从 1 秒提升至 100ms 级别。
这意味着：
- 你不能直接拿 11g 的 AWR 报告阈值去监控 12c+ 环境；
-
DBA_HIST_ACTIVE_SESS_HISTORY在 12c+ 中默认只保留 1 小时（ASH_MAX_DURATION参数控制），而 11g 是 1 天； - 如果目标库是金仓 KingbaseES 或其他国产库，它们根本没有 AWR 概念——所谓“兼容”，只是提供类似
sys_stat_activity的实时会话快照，不支持历史回溯分析。
最易被忽略的一点：AWR 快照编号（SNAP_ID）在跨库迁移后失去时间序列意义。它不再是单调递增的采集序号，而只是导入时的物理行号。任何依赖 SNAP_ID 做环比计算的脚本，都得重写为基于 END_INTERVAL_TIME 的时间窗口聚合。
