AWR组件在SYSAUX中占用过大根本不是数据过多，而是自动清理机制失效或配置失当导致历史快照长期滞留，常见于DBA_HIST_WR_CONTROL设置7天保留期但WRH$_ACTIVE_SESSION_HISTORY仍存30天前分区，需先查retention与实际快照范围是否匹配，再排查基线锁定、手动快照及19c ASTS组件等三大拦路虎。
AWR组件在SYSAUX中占用过大，根本不是“数据太多”，而是自动清理机制失效或配置失当导致历史快照长期滞留——最常见的是DBA_HIST_WR_CONTROL里设了7天保留期，但WRH$_ACTIVE_SESSION_HISTORY里还存着30天前的分区。
查AWR保留策略和实际快照范围是否对得上
保留策略只是“承诺”，不等于“执行”。先确认数据库是否真按设定清理：
- 运行
SELECT retention, interval, topnsql FROM dba_hist_wr_control;，看retention值（单位是分钟），比如604800=7天 - 再查真实快照跨度：
SELECT MIN(snap_id), MAX(snap_id), COUNT(*) FROM dba_hist_snapshot; - 如果
COUNT(*)远超retention对应理论快照数（例如7天应有约1008个快照，却有5000+），说明MMON没干活，或被基线/手动快照卡住
基线、手动快照、自定义保留是三大“清理拦路虎”
AWR不会删掉被基线保护、被手工创建或被dbms_workload_repository.modify_snapshot_settings显式延长保留期的快照：
- 查基线：
SELECT baseline_name, start_snap_id, end_snap_id FROM dba_hist_baseline;—— 每个基线都会锁死其区间内所有快照 - 查手动快照：
SELECT snap_id, snap_level, to_char(begin_interval_time, 'yyyy-mm-dd hh24:mi') FROM dba_hist_snapshot WHERE snap_flag = 1;（snap_flag = 1表示手动创建） - 基线不能随便删，但可确认是否还在用；手动快照若无业务依赖，可用
dbms_workload_repository.drop_snapshot_range清理
WRH$_表分区未收缩，DELETE残留碎片撑满空间
drop_snapshot_range底层走的是DELETE，不是TRUNCATE，所以只删行、不回收段空间，尤其在自动扩展文件+高碎片场景下，dba_segments.bytes居高不下：
- 典型症状：
WRH$_ACTIVE_SESSION_HISTORY占几十GB，但dba_hist_active_sess_history视图查不到对应快照 - 验证碎片：
SELECT segment_name, partition_name, bytes/1024/1024/1024 gb, blocks, empty_blocks FROM dba_segments WHERE segment_name = 'WRH$_ACTIVE_SESSION_HISTORY' AND tablespace_name = 'SYSAUX' ORDER BY gb DESC; - 真正释放空间得靠
ALTER TABLE sys.WRH$_ACTIVE_SESSION_HISTORY TRUNCATE PARTITION ...，但必须先确认该分区无快照依赖（查dba_hist_snapshot覆盖范围），且避开WRH$_ACTIVE_SES_MXDB_MXSN这类伪分区
19c+新增的SM/ADVISOR（ASTS）组件悄悄吃掉空间
Oracle 19.7默认开启SQL调优集（SQL Tuning Sets）自动捕获，相关LOB表如WRI$_SQLSET_PLAN_LINES会持续写入，且不走AWR保留策略：
- 在
v$sysaux_occupants里看到SM/ADVISOR排前三，尤其占用超20GB，基本就是它 - 查具体对象：
SELECT segment_name, bytes/1024/1024/1024 gb FROM dba_segments WHERE owner = 'SYS' AND segment_name LIKE 'WRI$_SQLSET%' AND tablespace_name = 'SYSAUX'; - 禁用自动捕获：
EXEC dbms_sqltune.set_tuning_task_parameter('AUTO_CAPTURE_SQL', 'OFF');，再清历史：EXEC dbms_sqltune.drop_sqlset('STS_NAME');
真正难处理的从来不是“怎么删”，而是删完后发现WRH$_SQL_PLAN索引分区还占着5GB、AUDSYS.AUD$UNIFIED又冒出来顶替位置，或者某张表因DISABLE ROW MOVEMENT无法SHRINK SPACE。空间问题永远是链式反应，动手前务必用v$sysaux_occupants定优先级，别一上来就跑TRUNCATE。
