awr数据占满sysaux主因是drop_snapshot_range仅删元数据而未释放物理空间，必须组合执行解绑基线、flush_awr强制收缩、大表shrink space三步才能真正降hwm。
AWR数据占满SYSAUX，八成不是“快照太多”，而是“删了但没真正释放”——DROP_SNAPSHOT_RANGE只删元数据，WRH$_表的高水位线（HWM）卡死不动，空间就永远下不来。
查清楚是不是AWR真在吃空间
别猜，直接看谁占得最多。用v$sysaux_occupants快速定位功能模块，比扫dba_segments更准、更快：
- 执行：
SELECT occupant_name, ROUND(space_usage_kbytes/1024/1024, 2) AS gb FROM v$sysaux_occupants WHERE space_usage_kbytes > 0 ORDER BY space_usage_kbytes DESC - 重点关注：
SM/AWR（排第一且远超其他项）、AUDSYS（统一审计）、SM/OPTSTAT（统计信息历史） - 如果
SM/AWR占比超60%，基本锁定；再补查：SELECT segment_name, bytes/1024/1024/1024 gb FROM dba_segments WHERE tablespace_name = 'SYSAUX' AND segment_name LIKE 'WRH$%' ORDER BY gb DESC，确认WRH$_ACTIVE_SESSION_HISTORY、WRH$_SQL_PLAN是否在前两位
为什么DROP_SNAPSHOT_RANGE删完空间不下来
这是最常踩的坑：Oracle底层走的是DELETE，不是TRUNCATE，所以行被标记为可覆盖，但段的高水位线（HWM）纹丝不动，dba_segments.bytes值根本不变。
-
DROP_SNAPSHOT_RANGE只清理元数据和索引条目，WRH$_表里的物理数据还在 - 基线（
dba_hist_baseline_details）锁住快照是隐形杀手：哪怕retention设为1天，只要baseline_type = 'STATIC'且start_snap_id很老，几百个快照就被钉死 - MMON进程卡住（尤其11g常见）会导致
WRH$_SQL_BIND_METADATA持续膨胀，伴随ORA-12751报错 - 分区表
HIGH_VALUE与实际数据脱节时，自动清理逻辑彻底失效
真正释放空间必须做的三件事
单做DROP_SNAPSHOT_RANGE等于白干。必须组合执行，缺一不可：
- 先解绑基线（如有）：
EXEC DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE(baseline_name => 'MY_BASELINE', cascade => TRUE)——cascade => TRUE是关键，否则物理数据不释放 - 删完快照后立刻触发强制刷新：
EXEC DBMS_WORKLOAD_REPOSITORY.FLUSH_AWR——唤醒MMON收缩逻辑，5–10分钟内才开始真正回收 - 对仍膨胀的大表手动收缩：
ALTER TABLE wrh$_sql_plan ENABLE ROW MOVEMENT→ALTER TABLE wrh$_sql_plan SHRINK SPACE CASCADE——注意：必须先启ROW MOVEMENT，否则报错
别碰这些“快招”，会出事
有些操作看似快，实则破坏数据字典或引发连锁故障：
- 直接
TRUNCATE TABLE WRH$_ACTIVE_SESSION_HISTORY或DROP TABLE：Oracle禁止，会报ORA-14404或损坏数据字典 - 只调
MODIFY_SNAPSHOT_SETTINGS改retention：只影响未来快照，对已有数据完全无效；单位是秒，86400才是1天，不是7 - 用
DELETE FROM WRH$_*手工删：锁表严重，阻塞新快照写入，还可能中断ADDM/ASH分析链路 - 忽略
AUDSYS：12c+统一审计日志也存SYSAUX里，查owner = 'AUDSYS'，清要用DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL，不能混用AWR命令
高水位线不降、基线没解绑、FLUSH_AWR没跟上——这三点漏掉任意一个，SYSAUX就还是满的。真实环境里，90%的“清理失败”都卡在这几步的衔接上。
