SYSAUX表空间被AWR撑满主因是WRH$分区表膨胀、基线锁定快照或drop_snapshot_range未配合flush_awr和SHRINK SPACE；需查dba_segments定位大分区表，清理基线后执行flush_awr及SHRINK SPACE，同时调整MOVING_WINDOW size和stats history retention。
SYSAUX表空间被AWR撑满，90%以上空间占用基本可锁定为 WRH$ 系列表、基线锁定或快照未真正释放——drop_snapshot_range 只删元数据，不腾物理空间，必须配合 flush_awr 和 SHRINK SPACE 才能见效。
查AWR实际占用：别只看v$sysaux_occupants，要盯dba_segments里真实对象
v$sysaux_occupants 能快速筛出“SM/ADVISOR”这类逻辑模块，但它不反映物理段膨胀细节。真正吃空间的是底层分区表，比如 WRH$_ACTIVE_SESSION_HISTORY 或 WRH$_SQL_PLAN，它们可能单个就占几十GB。
- 先跑：
SELECT owner, segment_name, segment_type, ROUND(bytes/1024/1024/1024, 2) gb FROM dba_segments WHERE tablespace_name = 'SYSAUX' AND segment_name LIKE 'WRH$%' ORDER BY bytes DESC FETCH FIRST 5 ROWS ONLY; - 重点关注
segment_type = 'TABLE PARTITION'的条目；若看到WRH$_SYSSTAT_PK占 92GB，说明不是快照太多，而是某个分区长期没清理 -
WRH$表名后缀里的数字是dbid+snap_id区间，不是随机命名，可据此判断是否跨库混入旧数据
删快照不释放空间？补flush_awr再SHRINK SPACE才管用
dbms_workload_repository.drop_snapshot_range 执行成功≠空间回收。它只删 WRH$_ 表的索引条目和元数据，表数据行仍留在高水位线（HWM）以下，dba_segments.bytes 不变。
- 删完必须立刻执行：
EXEC dbms_workload_repository.flush_awr;—— 强制触发MMON进程扫描并收缩段 - 若等5分钟还没降，直接对大表收缩：
ALTER TABLE wrh$_sql_plan ENABLE ROW MOVEMENT;→ALTER TABLE wrh$_sql_plan SHRINK SPACE CASCADE; - 禁用
DELETE FROM wrh$_xxx或整表TRUNCATE TABLE：会锁表、阻塞新快照写入，且无法清理LOB列（如WRH$_SQL_PLAN的OTHER_XML）
基线（baseline）锁住快照是隐形杀手，dba_hist_baseline_details必须查
哪怕 dba_hist_wr_control.retention 设为7天，只要存在 STATIC 基线或 MOVING_WINDOW 窗口过大，历史快照就会被钉住不删——drop_snapshot_range 对它们完全无效。
- 查基线现状：
SELECT baseline_name, baseline_type, start_snap_id, end_snap_id FROM dba_hist_baseline_details; - 若
start_snap_id是半年前的值，而当前最大snap_id是 100000，说明近万份快照被锁死 - 删静态基线：
EXEC DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE(baseline_name => 'MY_PERF_BASELINE', cascade => TRUE);——cascade => TRUE关键，否则元数据残留 - 删完别停：立刻
flush_awr，再查WRH$_表大小，确认是否下降
预防复发：调 window_size 比调 retention 更关键
很多人只改 MODIFY_SNAPSHOT_SETTINGS(retention => 604800)，但若 MOVING_WINDOW 基线的 window_size 是30天，系统仍会保留30天内所有快照——retention 形同虚设。
- 查当前窗口：
SELECT window_size FROM dba_hist_baseline WHERE baseline_type = 'MOVING_WINDOW'; - 同步调整：
EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_BASELINE_WINDOW_SIZE(window_size => 7); - 顺便收紧统计信息保留：
EXEC dbms_stats.alter_stats_history_retention(7);——WRI$_OPTSTAT表也常占十几GB
最易被忽略的一点：收缩操作需在非业务高峰执行，SHRINK SPACE CASCADE 会触发表级锁，且对含LOB的 WRH$_ 表可能耗时超预期；若空间已告急，优先用 TRUNCATE PARTITION（需先查清分区名），比等收缩更快。
