TechGuru在Oracle 19c RAC环境里听到“重建AWR”这个词，通常意味着事情已经到了比较严重的程度——SYSAUX表空间告警、AWR报告生成报错、快照历史查询不到数据、MMON后台日志刷错。但真正动手前，最该做的不是立刻找脚本，而是先判断“AWR到底坏在哪一步”。这篇就把我在19c RAC里重建AWR的完整判断思路、操作步骤和踩坑记录写出来，给同样被这套流程折腾过的DBA一个可以直接参考的落地清单。
先说清楚一个前提：AWR不是普通应用数据，它是Oracle性能自诊断的底层仓库，底层由MMON/MMNL进程持续写入，存放在SYSAUX表空间中，承载着ADDM、SQL Tuning Advisor、性能报告等一套依赖链。在RAC环境中，所有实例共享同一套AWR基础表，任何“重建”动作影响的都不只是当前节点，而是整个集群。所以这篇文章的内容偏重维护期操作，建议不要在业务高峰期直接照搬，必须结合自己环境的窗口安排。
1. 什么时候才需要“重建AWR”：先分清症状再动手
1.1 AWR仓库在19c里的基本构成
想判断要不要重建，先得知道AWR在你的19c库里到底留下了什么。它并不是一个独立表空间，而是在SYSAUX里的一组对象集合，主要分三类：
- WRH$开头的历史数据表，例如WRH$_ACTIVE_SESSION_HISTORY、WRH$_SQLSTAT、WRH$_SYSTEM_EVENT等，用来存快照采样数据。
- WRM$开头的元数据表，例如WRM$_SNAPSHOT、WRM$_WR_CONTROL等，记录快照ID、采集控制参数等。
- WRI$开头的内部对象，例如WRI$_OPTSTAT_HISTHEAD_HISTORY，和一些AWR相关包、同义词、视图。
其中最容易撑爆SYSAUX的，通常是WRH$_ACTIVE_SESSION_HISTORY，也就是ASH历史数据。AWR默认每隔一段时间采集一次，每次快照都会把这些增量数据写进WRH$表；如果并发很高，或者保留期配置过长，SYSAUX里AWR相关段的增长会非常明显。
1.2 哪些症状值得走到重建这一步
不是所有AWR异常都需要重建。我通常会根据下面几类现象判断：
| 症状 | 可能原因 | 该怎么处理 |
|---|---|---|
| 生成AWR报告时报ORA-13594、ORA-13595 | SYSAUX空间不足，或AWR操作所需段无法分配 | 先扩SYSAUX，再考虑重建 |
| dba_hist_snapshot查询为空或查询hang住 | 底层WRH$、WRM$表损坏，或对象状态异常 | 需要清理甚至重建AWR仓库 |
| 查询v$sysaux_occupants发现SM/AWR占用极高 | AWR保留数据过多，或无法自动清理 | 先清理历史快照，观察能否回收 |
| 手动执行DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT报ORA-06508等内部错误 | AWR相关包状态失效 | 重建前先尝试重编译无效对象 |
| alert日志中MMON进程不断报错，且和AWR表写入有关 | 底层对象状态不一致 | 需要系统诊断后走重建流程 |
遇到这些问题，先不要直接“一刀切”。很多情况下，AWR本身并没有损坏，只是历史快照积压导致SYSAUX空间压力大。这种场景下，正确做法是我后面会提到的轻量清理——只删除超出保留期的历史快照，而不是把整套AWR对象删掉重来。
1.3 明确不需要重建的几种情况
先说几个我实际见过的反面案例，避免你走弯路：
第一种，SYSAUX里的AWR段确实很大，但AWR报告可以正常生成。这时候只要手工删除旧快照，再做一次快照，空间通常能降下来。完全没有必要重建。
第二种，SYSAUX表空间使用率告警，但查v$sysaux_occupants以后发现大头是SM/OPTSTAT，不是SM/AWR。这是优化器统计信息历史表占空间，和AWR仓库关系不大。此时如果跑重建AWR的脚本，不但解决不了空间问题，还可能顺手把功能弄坏。
第三种，只是发现最近自动快照没有产生，但手动CREATE_SNAPSHOT能成功。那多半是某个节点的MMON进程异常，或者自动采集参数被改掉了，优先检查DBMS_WORKLOAD_REPOSITORY的interval设置，而不是重建。
我自己的习惯是：先用一条SQL看A