真正消耗磁盘空间的是WRH$_ACTIVE_SESSION_HISTORY等历史表，而非AWR快照本身；其膨胀源于快照保留策略不控制底层数据量、ASH归档密度随SNAP_INTERVAL缩短而激增、MMON清理滞后于写入，且分区不随RETENTION自动purge。
awr快照本身不直接“消耗大量磁盘空间”，真正吃空间的是 wrh$_active_session_history 这类历史表，尤其在默认配置 + 高负载场景下，它们会持续膨胀，远超你预期的“8天快照”所应占的空间。根本原因在于：快照保留策略只管顶层时间窗口，不管底层数据量；而 ash（active session history）数据是按秒采样、按会话写入的，它受快照控制但又部分独立——哪怕你把 retention 设为1天，只要 wrh$_active_session_history 的分区没被清理，空间就一直挂着。
为什么修改 SNAP_INTERVAL 反而可能让空间更紧张
缩短采集间隔（比如从60分钟改成15分钟）会显著增加快照数量，但更关键的影响是：每个快照都会触发一次对 ASH 数据的归档汇总。而 ASH 原始数据（V$ACTIVE_SESSION_HISTORY）默认每秒采样一次、保留1小时，归档进 WRH$_ACTIVE_SESSION_HISTORY 时，会按 Snap_id 分区存储。频繁快照 → 更多分区 → 更多索引和 LOB 段 → 空间增长呈非线性。实测中，将间隔调至15分钟，SYSAUX空间月均增长可翻2.3倍（尤其在高并发 OLTP 系统上）。
- 默认
SNAP_INTERVAL = '+00000 01:00:00.0'，每小时归档一次ASH区间数据 - 设为
15分钟后，每15分钟就做一次归档，但原始ASHbuffer 仍维持1小时容量，导致归档密度陡增 -
WRH$_ACTIVE_SESSION_HISTORY表本身不随RETENTION自动 purge 分区，必须依赖 MMON 后台进程扫描并清理“过期分区”，而该进程优先清理最老快照对应的数据，若快照太多、太密，清理节奏就跟不上写入节奏
哪些参数真正影响空间占用，且必须一起调
单改 SNAP_INTERVAL 或 RETENTION 都是半吊子操作。空间问题本质是“写入速率 vs 清理能力”的失衡，必须协同调整三个关键参数：
-
RETENTION：决定快照元数据和汇总统计的保留上限（单位：分钟），但不影响WRH$_ACTIVE_SESSION_HISTORY的物理删除时机 —— 它只告诉 MMON “哪些快照可以删”，不等于“对应的历史行就立刻删” -
TOPNSQL：默认30，调高到100会让WRH$_SQLSTAT和WRH$_SQLTEXT显著膨胀，尤其当系统存在大量短生命周期 SQL（如 ORM 自动生成语句）时，这部分可能占 SYSAUX 的25%+ -
ASH_BUCKET_COUNT（隐含参数，需谨慎）：控制V$ACTIVE_SESSION_HISTORY内存 buffer 大小，间接影响每次归档的数据量；但修改需重启实例，生产环境一般不动，优先用其他手段压空间
推荐组合（Oracle 11.2.0.4+）：BEGIN DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(retention => 14*1440, interval => 60, topnsql => 30); END; —— 即：保留14天、1小时1次、Top SQL 保持30条。这是多数中等负载 OLTP 系统的平衡点。
WRH$_ACTIVE_SESSION_HISTORY 分区不自动清理的典型表现
即使你确认 RETENTION 已设为14天，执行 SELECT MIN(snap_id), MAX(snap_id) FROM dba_hist_snapshot; 发现快照 ID 范围正常，但 SELECT COUNT(*) FROM wrh$_active_session_history; 仍返回数千万甚至上亿行，说明底层分区未被回收。这是 Oracle 11g 的常见行为，尤其当：
- 数据库曾长期停用 AWR（如维护窗口关闭了 MMON），导致分区堆积
- 存在手动创建的基线（
dba_hist_baseline_details），其覆盖范围内的快照及关联 ASH 数据会被锁定不删 - SYSAUX 表空间曾临时满过，MMON 清理失败后未重试，后续也不再主动补扫
验证方式：SELECT partition_name, high_value FROM dba_tab_partitions WHERE table_name = 'WRH$_ACTIVE_SESSION_HISTORY' ORDER BY partition_position DESC;
看最新分区的 HIGH_VALUE 是否明显滞后于当前时间（例如显示为 TO_DATE(' 2026-04-10 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')，而今天是2026-05-06）—— 这就是“分区卡住”的铁证。
最易被忽略的一点：AWR 空间压力从来不是单一参数问题，而是快照策略、基线管理、分区清理机制、甚至 SYSAUX 数据文件是否启用 autoextend 的综合作用。改完参数后不查 WRH$_ACTIVE_SESSION_HISTORY 分区状态，等于只拧紧了水龙头，却没关掉漏水的管道接头。
