Oracle SYSAUX表空间故障排查与清理实战指南

凌晨两点半，手机震了。屏幕上弹出一条告警：SYSAUX表空间使用率已超过95%。我揉了揉眼睛，第一反应不是赶紧去删数据，而是先问三个问题：它是怎么涨起来的？涨了多少？里面到底存了什么？

在Oracle数据库中，SYSAUX表空间是系统辅助表空间，从10g开始引入，专门用来承载AWR快照、统计信息历史、审计记录、优化器顾问、EM管理仓库等一堆“辅助功能”的数据。它的定位很清楚：帮DBA干活，替SYSTEM表空间分担压力。也正因为如此，它变成了一个什么都能往里塞的“杂物间”，一旦某个组件失控，整个表空间就会像吹气球一样鼓起来。更麻烦的是，SYSAUX空间耗尽会引发一系列连锁反应——AWR写不进去、统计信息收集失败、部分组件功能异常，严重时直接让数据库卡顿甚至hang住。

这篇文章不是泛泛的科普，而是把我处理这类故障的完整套路拆给你看：接到告警后的诊断动作、占用空间的真凶排查、安全的清理步骤、我踩过的三个坑，以及怎么把这类问题变成“不该再犯”的运维事故。无论你是刚接触Oracle的运维新人，还是已经被SYSAUX折磨过几回的老手，这套方法都值得直接拿来用。

1. 告警之后：先别动清理，用三个查询定位症状

很多人接到表空间告警的第一反应是“赶紧删点东西把空间腾出来”，这恰恰是最危险的。SYSAUX里存的不只是垃圾数据，还有大量性能诊断数据、历史统计信息和基线记录，删错了轻则丢失报表数据，重则影响优化器行为。我自己的习惯是：接到告警之后，先花5到10分钟做三件事，把症状彻底看清楚，再决定怎么动手。

1.1 第一次查询：整体使用率与增长速度

先看全局。通过DBA_DATA_FILES和DBA_TABLESPACE_USAGE_METRICS，确认SYSAUX当前的总大小、已用空间、剩余空间，以及过去一周的增长趋势。注意，使用率视图里的USED_SPACE单位是数据块，需要乘以块大小再换算成MB。

sql复制-- 查看表空间整体使用情况
SELECT a.tablespace_name,
       ROUND(a.bytes / 1024 / 1024, 2) AS total_mb,
       ROUND((a.bytes - b.free_bytes) / 1024 / 1024, 2) AS used_mb,
       ROUND(b.free_bytes / 1024 / 1024, 2) AS free_mb,
       ROUND((a.bytes - b.free_bytes) / a.bytes * 100, 2) AS used_pct
FROM   (SELECT tablespace_name, SUM(bytes) bytes
        FROM   dba_data_files
        WHERE  tablespace_name = 'SYSAUX'
        GROUP  BY tablespace_name) a,
       (SELECT tablespace_name, SUM(bytes) free_bytes
        FROM   dba_free_space
        WHERE  tablespace_name = 'SYSAUX'
        GROUP  BY tablespace_name) b
WHERE  a.tablespace_name = b.tablespace_name;

这个查询只是确认现状。真正有意思的是增长速率——我会把最近一周或一个月的AWR快照（如果还能生成的话）拉出来，看SYSAUX的占用曲线是“平缓爬坡”还是“垂直起飞”。如果是几天内突然涨了几个GB，那大概率是某个后台任务或者配置变更引起的，比如审计策略被打开、统计信息收集异常、AWR基线被大量创建。如果是缓慢增长，那多半是保留策略设置不当，AWR数据越攒越多。

1.2 第二次查询：SYSAUX内部占用排行

确认整体之后，马上把矛头指向SYSAUX的内部组件。Oracle提供了一个专门视图V$SYSAUX_OCCUPANTS，它能告诉你每个组件占了多少空间，以及组件的名称和描述。这是诊断的最高效入口。

sql复制-- 查看SYSAUX内部所有组件占用情况
SELECT occupant_name,
       occupant_desc,
       space_usage_kbytes / 1024 AS usage_mb,
       schema_name,
       move_procedure
FROM   v$sysaux_occupants
ORDER  BY space_usage_kbytes DESC;

一般情况下，排在最前面的会是SM/AWR（AWR快照仓库）、SM/OPT（优化器统计信息历史）、SM/ADVISOR（顾问任务结果），以及可能存在的AUD$审计表。这一步能让你快速锁定大致方向。但要注意，V$SYSAUX_OCCUPANTS只统计组件自己上报的空间，并不精确到每个段对象；有些组件上报的数值与实际段大小有偏差，尤其是AWR相关的表，所以这个视图只能作为方向参考，不能作为清理依据。

1.3 第三次查询：定位到具体段对象

方向定下来之后，直接下钻到DBA_SEGMENTS，按段大小排序，把SYSAUX里占用空间最大的前20个对象揪出来。这一步才是“破案”的关键。

sql复制-- 查看SYSAUX表空间中占用空间最大的前20个段
SELECT *
FROM   (SELECT segment_name,
               segment_type,
               owner,
               ROUND(bytes / 1024 / 1024, 2) AS size_mb,
               tablespace_name
        FROM   dba_segments
        WHERE  tablespace_name = 'SYSAUX'
        ORDER  BY bytes DESC)
WHERE  ROWNUM <= 20;

看到结果后，你通常会遇到两类情况。第一类是某个WRH$_开头的表（比如WRH$_ACTIVE_SESSION_HISTORY、WRH$_SQLSTAT）特别大，这就是AWR快照数据堆积；第二类是WRI$_OPTSTAT_HISTGRM_HISTORY、WRI$_OPTSTAT_OPR等统计信息历史表占据了大量空间。少数情况下，会出现AUDSYS.AUD$审计表超大，或者LOGMNR相关的日志挖掘辅助表失控。不管是哪一种，这一步都让你从“感觉SYSAUX爆炸了”变成“我知道是谁吃掉了空间”。

这三步做完，再回头看一眼最近的数据库变更记录：是不是有人改了DBMS_WORKLOAD_REPOSITORY的retention参数？是不是打开了统一审计？是不是最近做过大规模统计信息收集？把这些线索拼在一起，你的处置方案基本就成型了。

2. 空间都被谁吃了：SYSAUX组件占用画像

既然要处理，就得知道SYSAUX里到底都有哪些“常住居民”可能失控。我根据自己的运维经验，把常见的占用大户按“犯罪概率”排了个序，方便你对照排查。

2.1 AWR仓库：最大的“正常嫌疑犯”

AWR（Automatic Workload Repository）是SYSAUX里最出名也最容易膨胀的组件。Oracle默认每隔60分钟采集一次快照，并保留8天（不同版本略有差异），这些快照数据落在WRH$_前缀的多张表里。其中，WRH$_ACTIVE_SESSION_HISTORY（ASH历史）、WRH$_SQLSTAT、WRH$_SEG_STAT、WRH$_SYSTEM_EVENT这几张表往往是增长的主要来源。

AWR膨胀的常见原因有这么几个：

• 快照间隔被调小（比如从60分钟改成15分钟），导致数据量翻倍；
• 保留期被调得很长（比如90天甚至更长），且没人关注增长趋势；
• 创建了大量AWR基线（Baseline），基线范围内的快照不会被自动清理，即使过了保留期也会一直留着；
• 数据库负载极高，ASH采样数据非常密集，导致WRH$_ACTIVE_SESSION_HISTORY暴涨。

一个高负载的OLTP系统，AWR数据很可能占到SYSAUX总空间的60%到80%，这是最常见的情况。所以看到WRH$_开头的段很大，先别慌，这不一定代表系统出问题了，而是默认策略可能不够合理。

2.2 统计信息历史：优化器也爱吃空间

WRI$_OPTSTAT_HISTGRM_HISTORY是统计信息历史表，存的是每次DBMS_STATS收集时的直方图快照。Oracle默认保留31天的统计信息历史，用来支持“闪回统计信息”功能（即恢复某个时间点的优化器统计信息）。

问题出在频繁收集统计信息上。如果你的系统有定时任务每天收集多次统计信息，或者大批量执行DBMS_STATS.GATHER_*，每执行一次就会在历史表里插入一批数据。特别是那些有大表、大索引、多分区的库，一次全库统计信息收集可能产生几百MB的历史记录。几个月下来，WRI$_OPTSTAT_HISTGRM_HISTORY膨胀到几个GB都不稀奇。

2.3 审计记录：监管要求带来的“甜蜜负担”

12c之后，Oracle把统一审计（Unified Auditing）作为默认审计方式，审计日志文件如果配置为写入SYSAUX表空间，也会成为膨胀源。有些等保要求较高的系统，审计策略开得很全，每条登录、每个DDL、每次权限变更都记录，高峰时段审计数据增长非常快。

审计表的段名通常是AUDSYS.AUD$（或AUD$在SYS下），对应V$SYS_AUDIT_SESSION等视图。如果你发现这个表在DBA_SEGMENTS里排名靠前，那就不是简单的“清理慢速堆积数据”问题，而是审计策略和归档策略需要一起优化。

2.4 其他容易被忽略的组件

除了上面三个大头，SYSAUX里还住着一堆小住户。它们平时不起眼，但特定场景下也会突然长大。我把常见组件和它们的失控场景整理成了一个表格，方便你对照：

我在实际处理中见过一次LOG MNR日志挖掘辅助表把SYSAUX撑爆的案例，原因是某人反复开启LogMiner会话且未清理历史。所以，诊断时不要只盯着头部大段，偶尔也要看看那些“小透明”组件是否出现了异常增长。

3. 从诊断到清理：完整可执行的处置步骤

明确了元凶，接下来就是动手清理。我会按“先备份思路、再删数据、最后释放空间”的顺序，给你一套可以放心执行的步骤。

3.1 先确认安全边界，再碰数据

动手之前，建议先做两件事：一是理清你当前的AWR快照保留策略和范围，二是明确哪些历史数据可以删、哪些绝对不能删。我通常通过以下查询确认快照情况：

sql复制-- 查看当前快照ID范围
SELECT MIN(snap_id), MAX(snap_id), COUNT(*)
FROM   dba_hist_snapshot;

-- 查看当前AWR保留配置
SELECT * FROM dba_hist_wr_control;

DBA_HIST_WR_CONTROL里的RETENTION字段显示当前AWR数据保留时长（默认约8天），INTERVAL字段显示快照间隔。如果你看到快照ID区间特别大，说明历史跨度很长，或者区间里有大量基线快照被锁定。

这里要特别注意：业务高峰期、重大版本变更前、核心报表生成日这些关键时段的AWR数据，可能被业务方或开发人员用来做性能分析。如果你冒然全删了，后续做性能对比时会没有参照。我的习惯是：除了确认要保留的关键时段（通常保留最近30天的数据），其余严格按清理窗口执行，并把清理范围和保留策略记录在工作邮件或工单上。

3.2 AWR快照与基线的清理

确认范围后，使用DBMS_WORKLOAD_REPOSITORY包来删除快照。这个包是官方推荐的工具，不建议直接对WRH$_表做DELETE，否则极易引发锁和一致性风险。

sql复制-- 删除指定快照ID范围的AWR数据
EXEC DBMS_WORKLOAD_REPOSITORY.drop_snapshot_range(low_snap_id => 1, high_snap_id => 4000);

-- 删除指定时间点的快照（更推荐，避免手工查ID）
BEGIN
  DBMS_WORKLOAD_REPOSITORY.drop_snapshot_range(
    low_snap_id  => NULL,
    high_snap_id => NULL,
    low_time     => SYSDATE - 60,
    high_time    => SYSDATE - 30
  );
END;
/

如果空间特别紧张，你可以考虑把保留期直接调短，让MMON后台进程在不久的将来自动清理过期快照：

sql复制-- 将AWR保留期改为15天，快照间隔仍为30分钟
BEGIN
  DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(
    retention => 21600,  -- 单位是分钟，21600分钟=15天
    interval  => 30
  );
END;
/

注意：这里的interval不建议随便调小，高负载系统如果把快照间隔从60分钟改成15分钟，带来的写入量会成倍增加，可能很快又把SYSAUX塞满。改保留期也要基于监控数据来判断，最多保留业务上真正需要的周期，不要“感觉一个月够用”就直接设30天。

3.3 统计信息历史的清理

如果第2章定位到统计信息历史表占了大头，用DBMS_STATS.PURGE_STATS来清理。这个包会删除指定时间之前的统计信息历史，并且不影响当前生效的统计信息。

sql复制-- 清理7天前的统计信息历史
BEGIN
  DBMS_STATS.PURGE_STATS(SYSDATE - 7);
END;
/

清理完之后，还可以考虑调整统计信息历史的保留策略。从10g开始，Oracle允许你通过DBMS_STATS.ALTER_STATS_HISTORY_RETENTION设置保留天数：

sql复制-- 将统计信息历史保留周期调整为15天
BEGIN
  DBMS_STATS.ALTER_STATS_HISTORY_RETENTION(15);
END;
/

这个值不宜设置得太短，因为“闪回统计信息”功能依赖历史数据。如果保留期太短，某次统计信息收集后优化器行为异常，你连恢复的机会都没有。我自己的平衡点是15到30天，既有追溯能力，又不会让历史表无限膨胀。

3.4 审计记录的清理

如果审计表AUDSYS.AUD$是罪魁祸首，不能直接TRUNCATE或DELETE。统一审计的数据应该通过DBMS_AUDIT_MGMT包来管理，它会自动处理归档和清理。

先确认审计跟踪当前使用的位置和状态：

sql复制-- 查看审计跟踪属性
BEGIN
  DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(
    audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
    audit_trail_location => 'SYSAUX'
  );
END;
/

-- 初始化清理（首次使用时执行）
BEGIN
  DBMS_AUDIT_MGMT.INIT_CLEANUP(
    audit_trail_type         => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
    default_cleanup_interval => 24
  );
END;
/

-- 将当前审计记录归档，并清理7天前的旧记录
BEGIN
  DBMS_AUDIT_MGMT.CREATE_PURGE_JOB(
    audit_trail_type           => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
    audit_trail_purge_interval => 24,
    audit_trail_purge_name     => 'AUDIT_PURGE_JOB',
    use_last_arch_timestamp    => TRUE
  );
  DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP(
    audit_trail_type  => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
    last_archive_time => SYSTIMESTAMP - 7
  );
END;
/

如果你用的还是传统的FGA（Fine-Grained Auditing）或传统审计（AUDIT_TRAIL_DB_STD），那么对应的清理表可能是SYS.AUD$，需要单独用DBMS_AUDIT_MGMT的AUDIT_TRAIL_AUD_STD方式来清理。处理审计数据时，我建议和业务方确认一下合规要求，确认“审计记录最少需要保留多久”，再决定清到哪个时间点，别因为清理太激进惹上合规问题。

3.5 把空间真正交还给操作系统

数据删完，表空间的空间并不会自动缩小。因为Oracle段的高水位线（HWM）还停留在高位，即使表里的数据变少了，分配出去的区（Extent）也不会自动释放。所以你需要先整理段，再收缩数据文件。

对于AWR相关的WRH$_表，它们都是普通堆表，可以走标准的段收缩：

sql复制-- 先开启行移动（收缩的前提条件）
ALTER TABLE SYS.WRH$_ACTIVE_SESSION_HISTORY ENABLE ROW MOVEMENT;

-- 收缩段空间（同时整理高水位线）
ALTER TABLE SYS.WRH$_ACTIVE_SESSION_HISTORY SHRINK SPACE CASCADE;

-- 收缩完成后关闭行移动，避免后续不必要的行迁移开销
ALTER TABLE SYS.WRH$_ACTIVE_SESSION_HISTORY DISABLE ROW MOVEMENT;

对WRI$_OPTSTAT_HISTGRM_HISTORY也执行类似操作。如果遇到较大的表索引，也可以一并SHRINK。

做完段整理之后，再缩小数据文件。先查每个SYSAUX数据文件的大小和已用空间：

sql复制SELECT file_id,
       bytes / 1024 / 1024 AS size_mb,
       (bytes - blocks * 8192) / 1024 / 1024 AS free_mb
FROM   dba_data_files
WHERE  tablespace_name = 'SYSAUX';

然后用ALTER DATABASE DATAFILE RESIZE把文件缩小到一个合理大小。关键是目标大小要比当前实际已用空间稍微大一点，留出15%到20%的余量，避免下一步操作频繁扩容引发额外IO。假设当前数据文件8GB，实际数据占用5GB，那resize到6GB比较稳妥。

sql复制-- 将SYSAUX数据文件缩到6GB
ALTER DATABASE DATAFILE 5 RESIZE 6G;

如果RESIZE时报ORA-03297错误，说明文件里仍有段的高水位线超出了目标大小，需要回头检查是否还有未整理的大段，或者把目标值再调大一些。

4. 三个代价昂贵的坑：删除快照、truncate、resize的教训

处理SYSAUX的过程里，我踩过几个印象特别深的坑，写出来给你提个醒。这些坑在官方文档里都很少详细描述，但实际生产中一旦踩中，代价相当大。

4.1 大范围删除AWR快照时，undo和锁等待双双爆表

第一次清理AWR时，我直接执行了一个超大范围的drop_snapshot_range，从最早快照删到最近，中间跨度可能有一百多天。结果删除过程持续了很久，undo表空间不断增长，系统里还出现了大量行锁等待。原因在于：drop_snapshot_range本质上是对多个WRH$_表做批量DELETE，每张表的数据量都很大，事务产生的undo非常可观；同时删除过程中可能和其他会话（比如自动统计信息收集任务）产生锁竞争，导致数据库整体响应变慢。

现在我的做法是：分段删除。比如每500个快照ID提交一次，中间停顿几秒，给系统一个缓冲。同时提前观察undo表空间使用率，如果接近80%就要暂停，等undo空间释放后再继续。你也可以把删除操作放在业务低峰期执行，并且提前通知开发团队。

4.2 手贱TRUNCATE WRH$表：AWR直接写不进去

有一次我急于腾空间，看到WRH$_ACTIVE_SESSION_HISTORY最大的时候，脑子一热就想“直接TRUNCATE干净利落”。幸好最后没有执行，只做了测试库的验证。结果发现：直接TRUNCATE WRH$表会导致AWR相关的内部维护任务异常，后续MMON进程尝试写入AWR时找不到正确的统计元数据，还会报出奇怪的对象错误。而且很多WRH$_表之间有主外键关联，单表TRUNCATE会破坏数据一致性，甚至影响后续AWR报表生成。

更安全的方式是：如果数据已经确认不再需要，并且决定走非官方手段，也至少要先让相关任务停止，并用DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS调整策略，等待MMON自己清理。总而言之，非必要不用TRUNCATE，官方包的drop_snapshot_range已经足够应对绝大多数场景。

4.3 只RESIZE不先整理段：ORA-03297教你做人

还有一次，我删完数据之后想直接把数据文件缩小，结果连续报ORA-03297: file contains used data beyond requested RESIZE value。原因很简单：高水位线还挂在文件末尾，虽然段里很多块已经空了，但Oracle并不知道可以重复利用这些块，所以文件无法缩小。

这个错误提醒我：RESIZE前必须先做段整理。对大部分表做ALTER TABLE ... SHRINK SPACE可以解决，但要注意行移动的开关。另外，不是所有对象都能SHRINK——比如SYSAUX里某些对象如果是IOT（索引组织表）或包含函数索引，SHRINK会受限。这种情况下，可以考虑用ALTER TABLE ... MOVE，但MOVE会重建表并导致索引失效，必须提前规划重建索引的窗口。

4.4 清理完收工，忘了下一次保护

最后一个坑其实是运维意识问题。很多次清理完SYSAUX，空间是降下来了，但过了一两个月，告警又来了，而且往往比上一次更严重。原因很简单：只是“清”了症状，没有“治”根。AWR保留期还是90天，统计信息历史还是无限累积，审计策略也没有调整，数据当然会继续涨。

所以我现在把整个流程固化为四个步骤：诊断、清理、收缩、恢复监控。清理完成后，一定会重新检查AWR保留策略、统计信息历史保留策略、审计清理任务是否都处于合理状态，并且更新监控系统的基线阈值，让下一次异常在早期就被发现。

5. 防复发机制：监控基线、保留策略和例行维护

SYSAUX问题很难一次性根治，因为数据库会持续产生数据。但只要把监控、策略和例行维护串起来，完全可以把这类故障拒之门外。

5.1 建立SYSAUX空间增长趋势基线

监控不是“超过90%才报警”就完事，那样警报发生时往往已经很被动。我的做法是建立阶段性的趋势基线：每周记录一次SYSAUX总空间、已用空间，以及前十大段的空间占用，连续的记录会形成一个增长曲线。有了曲线，就能计算日均增长量，并以此反推“按当前增速，多少天后会达到告警阈值”。如果你的系统每天增长300MB，当前使用率70%，那大约10天后就会达到95%。这个预测比单纯告警早得多，完全来得及做预防性清理。

5.2 合理设置AWR保留策略

AWR保留策略没有一个“标准答案”，它完全取决于业务对历史性能数据的需求。我的建议是分场景定参数：

修改之后，要观察一到两周，确认SYSAUX空间是否回到一个稳定的增长斜率。如果还是增长很快，就要检查是否有异常的AWR基线被创建、是否有人手动修改过快照间隔。

5.3 例行维护清单

到了这里，我把自己常用的SYSAUX例行维护清单分享给你。这个清单大概每两周执行一次，也可以在每次大版本升级或业务大促后追加执行：

• 用V$SYSAUX_OCCUPANTS和DBA_SEGMENTS检查前十大段，记录变化趋势；
• 检查DBA_HIST_WR_CONTROL，确认AWR保留期没有被人改动；
• 检查统计信息历史保留期，确认DBMS_STATS.ALTER_STATS_HISTORY_RETENTION设置的值合理；
• 检查审计清理任务是否正常运行，审计表大小是否在可接受范围；
• 检查SYSAUX数据文件大小和可用空间，确定是否需要扩容或收缩；
• 查看最近的AWR快照生成是否正常，有没有因为空间不足导致采集失败的历史记录。

这套动作跑下来，通常只需要十来分钟，却能在早期发现90%的SYSAUX隐患。

5.4 我的最终建议：一个可靠的分层方案

综合这些经验，我建议你建立一个“日常监控+月度巡检+按需清理”的分层方案。日常监控负责发现异常趋势，月度巡检负责核对配置和趋势，按需清理只在数据膨胀到阈值时执行。三层配合，基本不会让SYSAUX空间问题发展成生产事故。

另外，如果你的SYSAUX空间经常在清理后没多久又涨回来，我建议认真检查一下应用层面有没有异常的定时任务，比如每隔一小时就做一次全库统计信息收集，或者有开发人员反复创建和删除AWR基线。这些问题往往比数据库本身的默认策略更容易造成空间暴涨。

最后再分享一个小技巧：处理SYSAUX问题的时候，我会在操作前用EXPORT或文本记录下当时的V$SYSAUX_OCCUPANTS和DBA_SEGMENTS结果，清理完再对比一次。这样不仅能确认清理效果，还能在后续复盘时清楚地知道哪些组件占了多少空间、清理了多少数据。这个习惯让我在处理多次类似故障时，越来越快，也越来越稳。

以上，就是我处理SYSAUX表空间使用率暴增的完整方法论。下次你的手机再在凌晨响起，你至少知道该从哪里下手了。