DROP_SNAPSHOT_RANGE仅删元数据不释放空间，必须执行FLUSH_AWR触发MMON收缩WRH$表并配合SHRINK SPACE才能真正回收SYSAUX空间。
直接删 DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE 不释放空间，必须配合 FLUSH_AWR 和 SHRINK SPACE 才能真正回收 SYSAUX 表空间。
为什么 DROP_SNAPSHOT_RANGE 后 SYSAUX 空间不下降？
这个过程只删元数据和索引项，WRH$_* 表里的历史数据行还在，高水位线（HWM）卡住不动。dba_segments 里看到的 GB 数不会变，ALTER DATABASE DATAFILE ... RESIZE 也缩不了——因为底层段没收缩。
常见错误现象：
- 执行完
DROP_SNAPSHOT_RANGE，查DBA_HIST_SNAPSHOT确实没了，但DBA_SEGMENTS中WRH$_ACTIVE_SESSION_HISTORY还占 20GB - 用
SELECT occupant_name, space_usage_kbytes FROM v$sysaux_occupants发现SM/ADVISOR或AWR仍排前三 - 误以为“删了就完事”，结果一周后 SYSAUX 又涨到 95%
删快照前必须验证 STATUS=0 且无 ASH 引用
Oracle 会拒绝删除正在被引用或异常状态的快照，静默跳过或报 ORA-13516，你以为删了，其实没删成。
执行前必查：
-
SELECT snap_id, status, begin_interval_time FROM dba_hist_snapshot WHERE snap_id BETWEEN 1000 AND 1100 ORDER BY snap_id;—— 确保所有status = 0（完成态），非 0 值（如 1=生成中、2=失败）不能删 -
SELECT COUNT(*) FROM dba_hist_active_sess_history WHERE snap_id IN (1000,1001,...);—— 若返回 >0，说明该快照正被 ASH 报告引用，需等报告生成结束或稍后再试 -
SELECT baseline_name, baseline_type FROM dba_hist_baseline_details WHERE start_snap_id = 1100;—— 若有STATIC基线覆盖该范围，DROP_SNAPSHOT_RANGE无效，得先DROP_BASELINE
删完必须立刻 EXEC DBMS_WORKLOAD_REPOSITORY.FLUSH_AWR
FLUSH_AWR 不是“可选步骤”，它是触发 MMON 主动扫描并收缩 WRH$_* 段的开关。不执行，后台不会自动收；等自动清理？可能要再等一小时甚至更久，且不一定触发收缩逻辑。
操作顺序不能错：
- 先确认快照已删干净：
SELECT MIN(snap_id), MAX(snap_id) FROM dba_hist_snapshot; - 立刻执行：
EXEC DBMS_WORKLOAD_REPOSITORY.FLUSH_AWR; - 等 5–10 分钟，再查大表空间：
SELECT segment_name, bytes/1024/1024/1024 gb FROM dba_segments WHERE segment_name LIKE 'WRH$%' AND tablespace_name = 'SYSAUX' ORDER BY gb DESC; - 若 GB 未降，说明物理数据还在，对单个表执行：
ALTER TABLE sys.WRH$_ACTIVE_SESSION_HISTORY ENABLE ROW MOVEMENT;→ALTER TABLE sys.WRH$_ACTIVE_SESSION_HISTORY SHRINK SPACE CASCADE;
长期更稳的方案是调 retention + window_size
手动删快照是救火，不是根治。SYSAUX 暴涨反复发生，八成是因为 MOVING_WINDOW 基线的 window_size 大于 retention，或者导入过其他库的快照（retention 显示为 +40150 天）。
检查与调整：
-
SELECT retention, snap_interval FROM dba_hist_wr_control;—— 若retention是 +40150，说明有外部导入快照，得用DBMS_SWRF_INTERNAL.DROP_SNAPSHOT_RANGE（隐含包，慎用）或重建 AWR -
SELECT baseline_name, window_size FROM dba_hist_baseline WHERE baseline_type = 'MOVING_WINDOW';—— 若window_size > retention，执行EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_BASELINE_WINDOW_SIZE(window_size => 7); - 最后统一设保留期：
EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(retention => 604800);（7天秒数）
最易被忽略的一点：FLUSH_AWR 后若没立刻 SHRINK SPACE，哪怕过了几天，那些 WRH$_* 表的 HWM 依然不会自己掉下来——空间就在那儿，等着下次写满再报警。
