AWR快照无法生成时，应优先排查SYSAUX空间、快照表误删或元数据不一致等问题，仅当WRM$等核心字典表损坏且无法修复时才重建；须确保ARCHIVELOG模式、VALID组件状态，并严格使用awr_install.sql重建，避免灾难性操作。
ORA-13502 或 AWR快照无法生成：先确认是否真要重建
重建 awr 存储库不是常规维护操作，而是最后手段。多数“awr 不工作”问题其实出在 sysaux 表空间满、dba_hist_snapshot 被误删、或 awr_flush_table 执行失败导致元数据不一致——这些都不需要重建。只有当 dbms_workload_repository 相关字典表（如 wrm$_snapshot、wrm$_database_instance）损坏且 oracle_home/rdbms/admin/awrrpt.sql 运行报 ora-600 / ora-13541 且无法通过 dbms_workload_repository.break_snapshot_range 修复时，才考虑重建。
- 检查
V$DATABASE的LOG_MODE和OPEN_MODE：必须为ARCHIVELOG+READ WRITE，否则awrload或重建脚本会静默失败 - 确认
DBA_REGISTRY中COMP_NAME = 'Oracle Database Packages and Types'状态为VALID；若为INVALID，重建前必须先运行utlrp.sql - 不要在 RAC 环境中单独重建某节点的 AWR —— 所有实例共享同一套
WR*表，必须停全部实例后统一操作
用 awr_remove.sql 清理旧数据比 drop tablespace 更安全
很多人看到 SYSAUX 满就直接 DROP TABLESPACE SYSAUX INCLUDING CONTENTS AND DATAFILES，这是灾难性操作。SYSAUX 不只存 AWR，还承载 Oracle Text、Spatial、Data Pump 元数据等，删掉等于毁库。真正该做的是用 Oracle 官方清理脚本。
- 以
sys用户执行：@?/rdbms/admin/awr_remove.sql，它会调用DBMS_WORKLOAD_REPOSITORY.REMOVE_SNAPSHOT_RANGE安全删除指定时间范围的快照，同时清理关联的WRH$历史表分区 - 若脚本报错 ORA-13516（“snapshot range overlaps with current retention”），说明当前 AWR 保留策略（
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS设置的retention）比你要删的时间还长，需先缩短保留期再重试 - 清理后务必执行
EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SYS', cascade => TRUE)，否则后续awrrpt.sql可能因统计信息陈旧而慢到超时
重建 AWR 字典表：只跑 awr_install.sql，别碰 catnoawr.sql
重建本质是重新创建 WRM$、WRH$、WRI$ 开头的基表和视图，但必须严格按 Oracle 内部依赖顺序。官方唯一支持方式是重跑 awr_install.sql，而非手动建表或执行 catnoawr.sql（后者是卸载脚本，执行即清空所有 AWR 对象且不可逆）。
- 路径必须准确：
@?/rdbms/admin/awr_install.sql，注意是rdbms不是rdbms/admin下的子目录；如果 ORACLE_HOME 设错，脚本会静默创建空表，后续插入快照时报 ORA-942 - 脚本会自动设置默认保留期为 8 天、采集间隔为 60 分钟；若需自定义，必须在脚本执行**完成且数据库重启后**，立即用
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS调整，不能在脚本中途改参数 - 执行完后检查
SELECT COUNT(*) FROM WRM$_DATABASE_INSTANCE，结果应 ≥1；若为 0，说明DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT尚未触发首次采集，需手动执行一次或等下一个采集周期
重建后第一个快照总失败？检查 WRH$_ACTIVE_SESSION_HISTORY 分区
常见现象：重建后 DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT 报 ORA-14400（“inserted partition key does not map to any partition”），或 awrrpt.sql 输出 “no data found”。根本原因是 WRH$_ACTIVE_SESSION_HISTORY 表的分区策略没同步更新，仍指向旧的高水位时间。
- 查当前最大分区：
SELECT PARTITION_NAME, HIGH_VALUE FROM DBA_TAB_PARTITIONS WHERE TABLE_NAME = 'WRH$_ACTIVE_SESSION_HISTORY' ORDER BY PARTITION_POSITION DESC FETCH FIRST 1 ROW ONLY - 若
HIGH_VALUE是类似TO_DATE(' 2023-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')的历史值，说明分区未重置，需手动合并并重建：ALTER TABLE WRH$_ACTIVE_SESSION_HISTORY COALESCE PARTITION - 合并后立即执行
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT，观察DBA_HIST_SNAPSHOT是否新增记录；若仍失败，检查DBA_SCHEDULER_JOBS中BSLN_MAINTAIN_STATS_JOB是否启用，它会影响 ASH 数据归档
最麻烦的不是重建动作本身，而是重建后那些没显式报错但快照数据缺失的静默异常——它们往往藏在分区边界、统计信息、或调度作业状态里，得一个个摸过去。
