是，DBMS_WORKLOAD_REPOSITORY是SYSAUX爆满的主因；AWR快照长期累积在WRH$%表中，需用DROP_SNAPSHOT_RANGE清理并刷新统计信息，基线保护和文件高水位线影响最终释放效果。
SYSAUX表空间爆满，DBMS_WORKLOAD_REPOSITORY 是元凶吗？
大概率是。awr快照默认保留8天，每小时1次，单实例每天约24条，长期不清理会持续写入 wrh$_ 系列表（如 wrh$_sqlstat、wrh$_active_session_history），这些全在 sysaux 里。不是所有 sysaux 涨幅都归它管，但一旦发现 dba_segments 中 wrh$% 表占空间前3，基本可以锁定。
用 DBMS_WORKLOAD_REPOSITORY 清理 AWR 快照的正确姿势
别直接删表或 truncate，Oracle 不认；也别只调 MODIFY_SNAPSHOT_SETTINGS 改保留天数——旧快照不会自动删，得手动触发清理。
-
EXEC DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(low_snap_id => 1234, high_snap_id => 5678)：按 ID 范围删，安全但需先查出 ID（见下一条） -
EXEC DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(low_snap_id => 0, high_snap_id => 999999999)：清空全部快照（慎用！会影响 ASH、ADDM 分析） - 查快照范围：
SELECT MIN(snap_id), MAX(snap_id), COUNT(*) FROM dba_hist_snapshot - 删完必须执行
EXEC DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO，否则 SYSAUX 里段空间不立即释放（高水位线卡住）
modify_snapshot_settings 的坑：改了参数 ≠ 空间立刻下来
这个过程只影响后续快照是否生成和保留多久，对已有快照完全无感。常见误操作是调了 retention 从 86400（24小时×60分×60秒=8天）改成 3600（1小时），然后等空间降——等不来。
- 单位是秒，不是天，
86400≠ 1天，而是 1天；3600= 1小时 - 实际生效需满足两个条件：当前快照时间戳 + retention ≤ 当前系统时间，且该快照未被任何基线（baseline）引用
- 被基线保护的快照，哪怕超期也不会被自动清理，得先用
DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE手动删基线
清理后 SYSAUX 还不缩容？重点看这三处
Oracle 不会自动回收数据文件物理空间，SYSAUX 文件本身大小不变，只是内部段变空。用户看到“已用空间下降”是 dba_segments 统计值，不代表磁盘释放。
- 检查段是否真释放：
SELECT segment_name, bytes/1024/1024 MB FROM dba_segments WHERE tablespace_name = 'SYSAUX' AND segment_name LIKE 'WRH$%' ORDER BY MB DESC - 如果 WRH$ 表体积明显变小，说明清理生效；若没变，可能是没删成功，或快照被基线/快照副本锁住
- 想收缩数据文件？
ALTER DATABASE DATAFILE '/path/to/sysaux01.dbf' RESIZE 2G前，必须确保高水位线下方有足够连续空闲空间，否则报错ORA-03297；更稳妥的是ALTER TABLE ... SHRINK SPACE COMPACT先整理碎片（仅限支持行移动的表）
