Oracle 19c RAC环境下AWR重建完整指南：从评估到恢复采集

1. 写在前面：什么情况才需要重建AWR，以及你该不该动手

先说结论：AWR重建不是一个例行操作，而是到了“不得不做”的时候才去做的补救手段。我接手过的不少客户环境里，隔三差五就有人因为SYSAUX表空间暴涨、AWR报表生成报错、或者历史快照数据异常，就想着把AWR整个推倒重来。但说实话，很多人对重建AWR的副作用根本没概念，上来就执行脚本，最后把基线数据和历史性能趋势全部清空，事后又追悔莫及。

在Oracle 19c RAC环境下，AWR底层存储依赖SYSAUX表空间，而RAC的每个实例都有独立的MMON后台进程，负责采集本实例的负载信息并写入SYSAUX中的WRH$表。如果只是SYSAUX空间增长过快，正确的做法是调整AWR保留策略和采集间隔，而不是直接重建。只有当出现以下情况时，我才会考虑重建AWR：

• AWR快照无法正常采集，MMON进程反复报错，alert日志中频繁出现ORA-135、ORA-1555等错误。
• 手工执行DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT时报错，提示AWR内部元数据损坏。
• 查询DBA_HIST_SNAPSHOT时，数据出现大量空洞或明显异常的时间戳错乱。
• 从低版本升级到19c后，AWR内部表结构或元数据不兼容，导致报表工具无法正常读取。

这篇内容我会以Oracle 19c RAC两节点环境为例，完整演示从评估、备份、停止采集、清理快照、重置元数据到恢复采集的整套流程，同时把我在生产环境踩过的坑一并写出来。建议你在动手之前，先把全文看完，特别是第4节的注意事项，能帮你省掉很多麻烦。

2. 重建前的现状评估：先搞清楚到底哪里出了问题

2.1 确认当前AWR运行状态

很多DBA一上来就直奔重建脚本，这是不对的。第一步应该是诊断现状，确认AWR到底处于什么状态、问题的根因是什么。就好比医生看病，连检查都不做就直接动手术，风险太大了。

在RAC环境下，你需要登录任意一个节点，以sysdba身份执行以下SQL，确认AWR整体的可用状态：

sql复制SQL> col instance_name format a15;
SQL> col startup_time format a30;
SQL> select instance_name, instance_number, status, startup_time 
     from gv$instance order by instance_number;

这个查询的目的是确认两个实例都处于OPEN状态，并且实例启动时间没有异常。如果某一个实例正处于实例恢复（INSTANCE RECOVERY）阶段，那么AWR采集本身就会受到影响，这时候重建AWR反而不是首要任务。

接着检查AWR快照的采集情况，使用如下SQL查看最近7天的快照生成记录：

sql复制SQL> col snap_interval format a20;
SQL> col retention format a20;
SQL> select * from dba_hist_wr_control;

这个视图能看到AWR的采集间隔（SNAP_INTERVAL）、保留时间（RETENTION）以及TOPNSQL的数量。默认情况下，19c的采集间隔是每小时一次，保留8天，TOPNSQL是30。如果你发现采集间隔已经被改成了5分钟甚至更短，那SYSAUX空间暴涨就怪不得别人了。

然后是检查快照记录本身是否正常：

sql复制SQL> select dbid, instance_number, min(snap_id), max(snap_id), count(*) 
     from dba_hist_snapshot 
     group by dbid, instance_number order by instance_number;

正常情况下，每个实例都应该有连续的快照记录，count(*)应该和保留时间内的小时数基本一致。如果你发现某实例的快照数严重偏少，或者min/max之间出现断层，说明AWR采集确实有问题。

2.2 评估SYSAUX空间占用情况

AWR数据全部存放在SYSAUX表空间，所以在重建之前，务必要搞清楚SYSAUX的占用情况，避免重建过程中因为空间不足导致更大问题。

sql复制SQL> col tablespace_name format a20;
SQL> col used_mb format 999999.99;
SQL> col free_mb format 999999.99;
SQL> col total_mb format 999999.99;
SQL> select tablespace_name, 
            round(sum(bytes)/1024/1024, 2) as total_mb 
     from dba_data_files 
     where tablespace_name = 'SYSAUX' 
     group by tablespace_name;

再细分到段级别，定位SYSAUX中占用空间最大的对象：

sql复制SQL> col segment_name format a40;
SQL> col segment_type format a20;
SQL> col owner format a15;
SQL> select owner, segment_name, segment_type, 
            round(sum(bytes)/1024/1024, 2) as size_mb 
     from dba_segments 
     where tablespace_name = 'SYSAUX' 
     group by owner, segment_name, segment_type 
     order by size_mb desc 
     fetch first 20 rows only;

如果占用最大的对象是WRH$相关表或WRH$_ACTIVE_SESSION_HISTORY等AWR基表，说明AWR确实是主要占用者。但如果占用最大的是其他组件（比如SM/ADVISOR、OPTSTAT、EM相关对象），那重建AWR并不能解决SYSAUX空间问题，你需要定位具体是哪个组件异常增长。

在我的实际经验中，有几次SYSAUX暴涨的根因其实是优化器统计信息自动收集任务（AUTO_STATS_ADVISOR_TASK）异常累积，跟AWR并没有直接关系。这种情况下盲目重建AWR，无异于给错病人做手术。

2.3 检查AWR相关内部对象状态

AWR重建的核心是清理WRH$等历史表数据并重置内部元数据状态。在19c中，AWR的内部元数据主要由WRR$_REPOSITION和若干内部控制表维护。为了确认当前元数据状态，可以执行：

sql复制SQL> select count(*) from wrh$_database_instance;
SQL> select count(*) from wrh$_control;

正常情况下这些表都应该有数据。如果WRH$_CONTROL为空，说明AWR控制信息异常，重建操作会更复杂一些。

另外，还需要检查AWR基线信息：

sql复制SQL> select count(*) from wrh$_baseline;
SQL> select count(*) from wrh$_baseline_template;

如果存在大量基线数据，重建前需要一并处理。这里必须提醒你，基线数据一旦删除不可恢复，而且基线不仅仅影响AWR报表，还和自动工作量仓库的保留策略相互关联，删除前务必确认业务是否需要这些基线的历史数据。

3. 重建AWR的标准操作流程：从备份到恢复采样的完整演练

3.1 第一步：备份关键数据

在RAC上重建AWR之前，我会强制要求做两步备份：一是备份AWR相关的数据，二是备份数据库的spfile参数文件。AWR数据备份可以使用Oracle自带的AWR导出工具，19c中命令如下：

bash复制-- 在oracle用户下执行，需要先设置环境变量
$ sqlplus / as sysdba
SQL> exec dbms_swrf_internal.awr_export_dump('AWR_BACKUP_2024', 'AWR_BACKUP');

这个存储过程会将当前AWR仓库中的快照数据导出到一个dump文件中。参数分别是dmp文件名和目录名。注意目录名需要先在数据库中创建对应的DIRECTORY对象：

sql复制SQL> create directory AWR_BACKUP as '/u01/backup/awr';

备份spfile相对简单，在grid或oracle用户下执行：

bash复制$ sqlplus / as sysdba
SQL> create pfile='/u01/backup/init19crac_before_awr_rebuild.ora' from spfile;

这里我多强调一句：备份不是走形式。我见过不止一次，DBA在重建完AWR后发现业务部门需要半年前某天的性能报告，而恰恰当时没有做导出备份，结果只能靠数据库自带的AWR基线碰运气。整个过程做完也就十分钟，别省这一步。

3.2 第二步：停止AWR自动采集

在重建过程中，如果AWR还在一刻不停地采集数据并写入SYSAUX，清理工作就会陷入“边删边写”的拉锯战，效率极低且可能造成数据不一致。所以首先要暂停AWR采集。

AWR采集的开关实际上是通过MMON的调度设置控制的。19c中可以通过DBMS_AWR_ADMIN或直接修改MMON的采集参数来实现。我推荐使用以下方法，在RAC的每个节点上执行：

sql复制SQL> exec dbms_workload_repository.modify_snapshot_settings(interval => 0, retention => 0);

注意，这里将INTERVAL设置为0表示停止周期性的自动快照。RETENTION设置为0需要小心，这会在某些版本中触发清理逻辑，所以在生产环境中，我更倾向于仅设置interval为0，等重建完成后再改回来。

如果你希望更彻底地停掉MMON的AWR采集活动，可以在19c中执行：

sql复制SQL> alter system set "_awr_enabled"=false scope=both sid='*';

这个隐含参数可以直接禁用AWR采集，而且重启后依然生效，因为写了scope=both。不过我需要提醒你：这个参数是隐藏参数，Oracle官方并不保证在所有版本中行为一致，执行前建议先在测试环境验证。

在RAC环境里，执行上述命令后，建议在另一个节点上也确认一下参数已经生效：

sql复制SQL> show parameter _awr_enabled;
SQL> select instance_name, value from gv$parameter where name='_awr_enabled';

3.3 第三步：清理AWR快照和基线数据

停掉采集之后，就可以开始清理历史数据了。这一步是整个重建过程的核心，也是最耗时的一步。AWR的历史数据存储在SYSAUX表空间的WRH$表中，如果数据库运行了很久没有清理过，这些表可能积累上亿条记录，直接DELETE会非常缓慢，而且会产生巨大的UNDO和REDO日志。

我推荐使用Oracle提供的DBMS_WORKLOAD_REPOSITORY包来按快照范围删除，这样可以避免手工DELETE带来的各种风险。

首先删除所有基线定义，在19c中基线分为固定基线和移动基线，都需要清理：

sql复制SQL> select distinct baseline_name from dba_hist_baseline;
SQL> exec dbms_workload_repository.drop_baseline(baseline_name => 'BASELINE_NAME', cascade => true);

如果基线数量较多，或者你想一次性清理所有基线，可以直接从数据字典层面操作，但我不建议在生产环境直接DELETE字典表。有一个相对安全的做法是循环调用DROP_BASELINE：

sql复制SQL> declare
       cursor c is select distinct baseline_name from dba_hist_baseline;
     begin
       for rec in c loop
         begin
           dbms_workload_repository.drop_baseline(baseline_name => rec.baseline_name, cascade => true);
         exception when others then null;
         end;
       end loop;
     end;
     /

这个PL/SQL块会忽略个别基线删除失败的场景，保证整体流程可以继续。但注意使用cascade=>true会把基线关联的快照数据一并删除，所以再次强调执行前必须和业务确认。

接下来按快照ID范围清理快照数据。如果你的AWR保留时间比较长（比如90天），快照ID可能跨度很大。可以按快照ID区间分批次删除，避免一次性删除带来的事务过大：

sql复制SQL> declare
       v_min_snap_id number;
       v_max_snap_id number;
     begin
       select min(snap_id), max(snap_id) into v_min_snap_id, v_max_snap_id from dba_hist_snapshot;
       dbms_output.put_line('Min snap_id = ' || v_min_snap_id || ', Max snap_id = ' || v_max_snap_id);
       -- 每500个快照为一批次删除
       for batch_start in (select snap_id from dba_hist_snapshot where snap_id >= v_min_snap_id and snap_id <= v_max_snap_id and mod(snap_id - v_min_snap_id, 500) = 0) loop
         dbms_workload_repository.drop_snapshot_range(low_snap_id => batch_start.snap_id, high_snap_id => batch_start.snap_id + 499);
         commit;
       end loop;
     end;
     /

这里用mod函数做批次切分，每处理500个快照提交一次。这样做的好处是事务大小可控，不会撑爆UNDO表空间，也方便定位某个批次失败的问题。

如果你确认要把AWR历史数据清得干干净净，还可以使用DBMS_SWRF_INTERNAL包中的一个更底层的过程：

sql复制SQL> exec dbms_swrf_internal.cleanup_awr;

这个过程会清理AWR仓库中的所有快照数据，包括WRH$表、WRM$表等。但需要注意，它不一定清理所有AWR辅助对象，比如SQL计划基线等，而且不同版本下的行为差异较大。在19c RAC上使用该命令时，我遇到过个别节点提示ORA-13595，原因是远端实例的MMON尚未完全停止采集任务，所以如果你执行时报错，不要慌，多半是第3.2节的停采集动作没有完全生效。

最后还要清理一个很隐蔽的数据：WRH$_ACTIVE_SESSION_HISTORY。这张表记录了ASH数据，它的数据量和保留时间由ASH的保留策略控制，不完全受AWR清理影响。如果你需要连这个一起清理，可以执行：

sql复制SQL> alter session set "_ash_retention"=0;
SQL> exec dbms_awr.pls_awr_ash_cleanup;

说实话，ASH数据和AWR是两个体系，重建AWR时我个人建议一并处理，因为如果留着ASH历史数据，SYSAUX空间并不会收缩多少。但你也要知道，一旦清理之后，Active Session History的历史报告也无法生成了，这个需要提前跟业务确认。

3.4 第四步：重置AWR内部元数据

清理完快照和基线之后，AWR的“数据”层面已经基本干净，但“元数据”的某些状态可能还残留着，比如DBID与实例的映射关系、快照序列号等。在19c RAC中，这些元数据分散在WRM$表（AWR元数据表）中。

我常用的做法是调用DBMS_SWRF_INTERNAL包来清除并重建AWR的元数据信息：

sql复制SQL> exec dbms_swrf_internal.clear_awr;

注意，CLEAR_AWR和CLEANUP_AWR是两回事，前者清理的是AWR的内部元数据，后者清理的是实际数据。在19c中，执行CLEAR_AWR会自动重置AWR的内部快照序列和数据库实例映射信息。

如果你发现CLEAR_AWR执行后有些残留，还可以手动清理以下几张核心元数据表：

sql复制SQL> delete from wrm$_snapshot;
SQL> delete from wrm$_database_instance;
SQL> delete from wrm$_control;
SQL> commit;

但这里我必须非常严肃地提醒你：直接对WRM$表执行DELETE属于高危操作，因为这些表之间有外键关联，且SYS用户操作字典表不受约束检查保护，一旦误删或删错，AWR可能彻底无法使用，甚至影响数据库启动。只有在CLEAR_AWR和CLEANUP_AWR都执行失败、且你清楚自己在做什么的情况下，才建议走到这一步。

在RAC环境下操作时，务必确认你连接的是哪个实例，以及当前会话的实例号：

sql复制SQL> select instance_number, instance_name from v$instance;
SQL> select instance_number, instance_name from gv$instance order by instance_number;

如果元数据是跨实例共享的（实际上WRM$表存放在当前DB的SYSAUX中，RAC各实例访问的是同一份数据），那么只需要在一个节点上执行清理即可，不能在两个节点同时执行，否则会出现资源竞争。

3.5 第五步：恢复AWR自动采集并验证

到这一步，AWR重建的主体工作已经完成。接下来要恢复自动快照，并验证AWR功能是否完全正常。

恢复采集同样使用DBMS_WORKLOAD_REPOSITORY包，我在生产环境中一般恢复为默认的1小时间隔和8天保留：

sql复制SQL> exec dbms_workload_repository.modify_snapshot_settings(interval => 60, retention => 8*24*60, topnsql => 30);

这里的INTERVAL参数单位是分钟，RETENTION参数单位也是分钟，8天就是11520分钟。TOPN SQL设置为30表示每个快照保留Top 30条SQL，如果你需要更细粒度的SQL分析，可以设置成50或者100，但相应的SYSAUX占用也会增加。

如果你之前用隐含参数停用了AWR，还需要重新启用：

sql复制SQL> alter system set "_awr_enabled"=true scope=both sid='*';

然后手工生成一个快照来验证AWR采集功能是否正常：

sql复制SQL> exec dbms_workload_repository.create_snapshot();

执行成功后再查一下快照记录：

sql复制SQL> select instance_number, snap_id, begin_interval_time 
     from dba_hist_snapshot 
     order by snap_id desc 
     fetch first 4 rows only;

确认两个实例都能生成快照，并且时间戳正常。这一步非常关键，因为在实际操作中，我遇到过清理完AWR后，实例1能正常采集但实例2生成快照时报ORA-13519，原因就是实例2的MMON进程还持有旧的AWR状态，重启实例后问题才消失。

最后再做一次AWR报表生成测试：

bash复制SQL> @?/rdbms/admin/awrrpt.sql

选择生成的报表类型、天数范围和快照范围，验证报表可以正常输出。如果你在RAC上想生成集群范围的AWR报表，可以使用awrrpt.sql按DBID生成，或者用awrrpti.sql指定实例号。生成成功说明AWR重建基本完成。

4. 重建过程中的常见问题与排查技巧实录

4.1 清理速度极慢，卡在某个快照范围上

清理AWR快照时经常遇到的第一个坑就是执行DROP_SNAPSHOT_RANGE时速度极慢，一个批次跑几十分钟还没结束。这通常是因为WRH$表的数据量巨大、索引碎片化严重，或者UNDO表空间不够导致回滚段频繁切换。

我实践中比较有效的做法是：先查一下WRH$表的最大分区和行数，预估数据量，然后按小时甚至半小时为区间分批次删除。另外，可以在清理前先对影响较大的WRH$表做一次索引检查，如果发现索引碎片化严重，可以考虑在清理完成后重建索引，而不是在清理过程中频繁维护索引。

如果确实需要快速清空AWR历史数据，且业务允许，可以使用TRUNCATE方式清空WRH$分区表的分区，但这种方式在RAC环境里风险较高，因为各实例的MMON可能仍在对这些分区写入，建议在停采集后、且低峰期执行。

sql复制SQL> select partition_name, num_rows from dba_tab_partitions 
     where table_name='WRH$_ACTIVE_SESSION_HISTORY' 
     order by partition_name;

如果要TRUNCATE分区，可以用类似下面的命令，但务必先确认所有实例的AWR采集已经停止：

sql复制SQL> alter table wrh$_active_session_history truncate partition SYS_P1234;

这里我再补充一个经验：TRUNCATE只清除高水位线以下的数据，不一定能完全释放分区空间，所以你还需要结合SHRINK SPACE或MOVE操作来收缩物理空间。不过在19c中，SYSAUX中的表默认不允许MOVE，需要先关闭行移动，这个操作本身就比较敏感，我建议非必要不做。

4.2 清理完成后SYSAUX空间没有释放

很多DBA在清理完AWR数据后发现，SYSAUX表空间的使用率并没有显著下降，查询DBA_SEGMENTS发现WRH$表的空间占用依然很高。这个现象很常见，因为DELETE数据只是标记为“可重用”，并不会立即把空间归还给操作系统。表的高水位线（HWM）还停留在原来的位置。

解决这个问题的方法是收缩AWR相关表占用的空间。但在19c中，SYSAUX表空间中的AWR表通常是分区表，直接在表级别执行SHRINK SPACE很可能报ORA-10631。我遇到过的几个可行做法是：

• 使用ALTER TABLE ... SHRINK SPACE CASCADE，前提是表支持行移动。
• 如果表是分区表，可以对单个分区执行SHRINK。
• 如果表不支持SHRINK，可以考虑导出AWR所需数据后重建表（这属于彻底重建设计，非常麻烦，不推荐在RAC生产环境中做）。

比较稳妥的方法是：在确认AWR数据已清理干净后，对SYSAUX表空间添加一个新的数据文件，再将原数据文件的内容迁移过去，然后删除旧数据文件。但说实话，在RAC环境中实施这个方案会影响所有实例，操作窗口要求很高，必须提前评估停库时间。

4.3 RAC多节点环境下出现ORA-13595

ORA-13595在RAC重建AWR时的出现频率相当高，报错信息通常是“AWR operation failed because the MMON is not enabled in the database”。这个错误往往不是AWR功能本身损坏了，而是你在执行清理操作时，某个实例的MMON进程没有正常运行，或者AWR采集被禁用。

排查步骤如下：

第一步，确认所有实例的MMON进程状态：

bash复制$ ps -ef | grep mmon

每个节点上应该有至少两个MMON相关的进程（如ora_mmon_xxx），如果某个实例没有MMON进程，说明实例的MMON后台进程异常，需要结合alert日志排查。

第二步，检查AWR采集开关：

sql复制SQL> show parameter _awr_enabled;

如果某个实例的参数值是false，AWR操作就会直接失败。

第三步，如果是执行CLEANUP_AWR时在某个节点上报ORA-13595，可以尝试在该节点上先手工触发一次MMON唤醒：

sql复制SQL> exec dbms_workload_repository.create_snapshot();

如果手工快照能成功，说明MMON基本正常，再重新执行清理操作通常就能通过。

我遇到过最棘手的一次情况是，三个节点中有一个节点的MMON进程挂死，Oracle 19c自动重启了该实例的MMON，但AWR内部状态没有恢复，导致执行任何AWR相关操作都报ORA-13595。最终是通过重启该实例解决的，所以如果你的环境允许，而且其他手段都无效，实例级重启也是一条路。

4.4 AWR重建后部分历史SQL的Execution Plan丢失

这个问题容易被忽略。AWR重建会清理WRH$表，但SQL执行计划和SQL文本的历史信息，一部分存储在WRH$_SQL_PLAN和WRH$_SQLTEXT中，如果这些被清理了，那么你之后用AWR报表或者DBA_HIST_SQLTEXT查询过去的SQL文本时，会有大量记录缺失。

更麻烦的是，AWR重建并不影响共享池中缓存的SQL信息，但数据库重启后，这些缓存信息会丢失，等于历史SQL性能数据彻底断层。

如果你业务上有较长周期的SQL性能追踪需求，建议在AWR重建前通过以下方式备份SQL执行计划：

sql复制SQL> exec dbms_workload_repository.create_sqlset('SQLSET_BEFORE_AWR_REBUILD', 'SQLSET_DESC');
SQL> exec dbms_workload_repository.modify_sqlset_attributes('SQLSET_BEFORE_AWR_REBUILD', 'LOAD', 'YES');
SQL> exec dbms_workload_repository.capture_sqlset('SQLSET_BEFORE_AWR_REBUILD');

这条SQL Tuning Set的容量可能要占一定SYSAUX空间，但相比AWR历史数据来说小很多，属于性价比非常高的备份方案。

4.5 重建后基线数据完全丢失，移动基线窗口异常

清理基线的副作用比很多人想象中要大。Oracle 19c中，除了用户手工创建的固定基线（Static Baseline）之外，还有系统自动维护的移动基线（Moving Window Baseline）。如果你不小心连系统基线一起删了，可能会引起AWR报表中基线相关字段显示异常。

修复方法很简单，重建默认的移动基线窗口：

sql复制SQL> exec dbms_workload_repository.modify_baseline_window_size(8);

这个命令会重新创建8天的移动窗口基线。执行后可以通过以下SQL确认：

sql复制SQL> select baseline_name, baseline_type, moving_window_size from dba_hist_baseline;

这里需要注意，MOVING_WINDOW_SIZE的单位是天，而且它必须小于等于AWR保留时间。如果你的保留时间设的是7天，移动窗口却要设8天，系统会报错。合理搭配是：保留时间=14天，移动窗口=7天或者8天。

5. 重建AWR时的参数选型建议与经验总结

5.1 快照间隔、保留时间与TOPNSQL之间的平衡

AWR重建完成后，恢复采集参数时不要无脑用默认值，要根据业务场景合理设置。

• 如果是交易型业务（OLTP），快照间隔保持默认60分钟足够。如果业务对性能波动敏感，可以缩短到30分钟，但SYSAUX的增量会大约翻倍。
• 如果是批处理或者报表系统（OLAP），夜间有大量作业运行，可以考虑增加快照频率，比如夜间每15分钟一次，白天1小时一次。19c中不支持按时间段配置不同的快照频率，所以你需要妥协，要么全程15分钟，要么全程1小时。
• 保留时间方面，如果业务要求能生成近一个季度的性能趋势，那就把RETENTION设成90天，但SYSAUX的空间占用也会水涨船高，你需要提前预留空间。
• TOPNSQL建议不要低于30。如果业务有大量SQL，可以设置成100，但不建议超过200，因为TOPNSQL越大会导致WRH$_SQLSTAT等表的数据量急剧膨胀。

我个人的习惯配置是：INTERVAL=30分钟，RETENTION=30天，TOPNSQL=50。这样既兼顾了性能分析的细粒度，又能覆盖一个月的趋势数据，SYSAUX空间增长也比较可控。当然，如果你的SYSAUX表空间只有10GB，这个配置可能会比较紧张，需要根据实际空间动态调整。

5.2 重建后SYSAUX的空间监控

AWR重建完成后，建议至少持续观察一周的SYSAUX空间增长趋势，判断当前参数配置是否合理。

sql复制SQL> select to_char(begin_interval_time, 'YYYY-MM-DD') as day,
            round(sum(space_used_total)/1024/1024, 2) as sysaux_mb
     from dba_hist_sysstat 
     where stat_name = 'Space used' 
       and begin_interval_time > sysdate - 7 
     group by to_char(begin_interval_time, 'YYYY-MM-DD')
     order by 1;

如果你发现SYSAUX以每天超过1GB的速度增长，说明参数配置可能需要优化，或者存在其他组件异常累积。正常情况下，30分钟快照间隔、50条TOPNSQL的配置下，SYSAUX每天增长一般在300MB到800MB之间，具体取决于业务负载强度。

5.3 从重建到预防：避免再次走到重建这一步

最后聊点建议。AWR重建终究是治标不治本，真正的问题是为什么AWR会走到需要重建的地步。根据我的经验，原因无非就那几类：快照间隔过密、保留时间过长、TOPNSQL设置过大、SYSAUX空间规划不足，以及部分第三方监控工具频繁读取AWR数据导致内部对象异常。

如果你不想下一次再熬夜执行重建流程，我有几个非常实用的建议：

• 给SYSAUX设置独立的监控告警，使用率超过70%就提前介入，不要等满了再处理。
• 定期（比如每季度）执行一次AWR健康检查，关注DBA_HIST_SNAPSHOT是否有空洞，WRM$_CONTROL状态是否正常。
• 在变更窗口内，把快照间隔临时拉长到2小时，降低AWR写入压力。
• 如果DBA_HIST_ACTIVE_SESS_HISTORY表数据量特别大，可以单独评估关闭ASH或者缩短ASH保留时间，这能显著降低SYSAUX增长压力。

我在实际运维中踩过几次坑之后，现在养成了一个习惯：每个月都会花十分钟检查一次SYSAUX的空间走势和AWR快照的完整性。这样做最大的好处是，问题还在苗头阶段就被发现，根本不需要走到重建AWR这一步。即使是真遇到了非重建不可的场景，手里有完整的监控数据和参数记录，重建起来也会快很多，不用临时去翻文档和猜参数。