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报告时报OR |