必须用dbms_workload_repository接口清理wrh$%表，直接truncate或drop会破坏数据字典一致性；先查v$sysaux_occupants定位awr占比，再用drop_snapshot_range显式删除快照，并执行flush_database_monitoring_info更新统计，否则空间不释放、高水位线卡死。
直接删 wrh$% 表或手动 truncate table 会破坏数据字典一致性，oracle 不允许；必须用 dbms_workload_repository 接口清理，否则空间不释放、高水位线卡死、后续快照仍失败。
查清楚到底是谁在吃空间
先确认是不是 AWR 真的占了大头，而不是审计（AUDSYS）、统计信息历史（SM/OPTSTAT）或其他组件：
- 运行
SELECT occupant_name, space_usage_kbytes/1024/1024 AS gb, schema_name FROM v$sysaux_occupants ORDER BY space_usage_kbytes DESC—— 若SM/AWR排第一且远超其他项，基本锁定 - 再查具体表：
SELECT 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 gb DESC—— 常见大户是WRH$_ACTIVE_SESSION_HISTORY、WRH$_SQLSTAT、WRH$_SYSSTAT - 注意：如果
AUDSYS下的 LOB 段（如SYS_LOB0000091784C00014$）也很大，得另走DBMS_AUDIT_MGMT清理路径，不能混为一谈
用 DROP_SNAPSHOT_RANGE 清理快照（不是改 retention）
MODIFY_SNAPSHOT_SETTINGS 只影响未来快照生成策略，对已存在的快照完全无效。必须显式调用 DROP_SNAPSHOT_RANGE 才能真正删数据：
- 先查可用范围：
SELECT MIN(snap_id), MAX(snap_id), COUNT(*) FROM dba_hist_snapshot - 安全清理旧快照（例如删掉 1 天前的）：
EXEC DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(low_snap_id => 0, high_snap_id => 12345)—— 注意：ID 要查准，别误删最近 24 小时的诊断数据 - 慎用全清：
EXEC DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(low_snap_id => 0, high_snap_id => 999999999)—— 会丢失所有 AWR 历史，ADDM、ASH 分析失效 - 基线保护的快照不会被删：若
dba_hist_baseline中有记录，需先EXEC DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE(baseline_name => 'xxx', cascade => TRUE)
清理后空间还不下来？关键在 FLUSH 和高水位线
删完快照，dba_segments 里 WRH$% 表体积没变小？常见原因就三个：
- 没执行
EXEC DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO—— 这步强制刷新内存中的段使用统计，否则dba_segments.bytes不更新，监控看到“没释放” - 被基线锁住但没查到：检查
SELECT * FROM dba_hist_baseline和SELECT * FROM dba_hist_snapshot WHERE baseline_id != 0 - 物理文件不缩容是正常行为：Oracle 不自动 shrink 数据文件。
ALTER DATABASE DATAFILE '/u01/oradata/xxx/sysaux01.dbf' RESIZE 2G前，必须先确认dba_segments统计值已下降，否则会报错 ORA-03297
长期预防：别只调 retention，要控 snapshot frequency + level
默认每小时一次、保留 8 天，在 OLTP 系统上极易堆积。尤其 12c 后 level=ALL 会采集大量额外字段（如绑定变量、PL/SQL 信息），空间消耗翻倍：
- 查当前设置：
SELECT snap_interval, retention FROM dba_hist_wr_control - 合理调整（示例）：
BEGIN DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(interval => 60, retention => 7*24*60, topnsql => 50); END;——topnsql控制 Top SQL 数量，减少WRH$_SQLSTAT膨胀 - 避免设
level=ALL：除非做深度 SQL 诊断，否则保持默认level=TYPICAL即可 - 定期巡检：每周跑一次
v$sysaux_occupants查询，比等告警更主动
最易忽略的一点：DROP_SNAPSHOT_RANGE 是 DML 操作，会产生大量 UNDO 和归档日志；生产库执行前务必确认归档空间充足，且最好避开业务高峰。删完不 flush，等于白删。
