最快清理WRH$分区表需先确认快照依赖和分区状态，否则触发ORA-13505或AWR报告失效；重点查WRH$_ACTIVE_SESSION_HISTORY等大头对象，用TRUNCATE PARTITION清理并补SHRINK SPACE释放空间。
直接清理 WRH$ 开头的分区表最快，但必须先确认快照依赖和分区状态，否则会触发 ORA-13505 或导致 AWR 报告失效。
查清谁在占 SYSAUX：先跑 v$sysaux_occupants
别急着删，先看 SYSAUX 里到底谁吃掉了最多空间。这个视图能快速列出所有“住户”及其用量：
-
SM/ADVISOR（优化器统计历史）和AUDSYS（统一审计）在 19c+ 中常排前两位，不一定是 AWR 本身 - 如果
AWR或SM/AWR占比超 60%，再深入查 AWR 相关段 - 注意
move_procedure列：值为DBMS_AWRF_INTERNAL.MOVE_WRR的表示支持安全迁移，不是所有对象都适合直接TRUNCATE PARTITION
定位大头表：重点盯 WRH$_ACTIVE_SESSION_HISTORY
它通常是 SYSAUX 里最大的单个对象，尤其在高负载库中动辄几十 GB：
- 查真实大小：
SELECT segment_name, partition_name, bytes/1024/1024/1024 size_gb FROM dba_segments WHERE segment_name LIKE 'WRH$_ACTIVE_SESSION_HISTORY%' AND tablespace_name = 'SYSAUX' ORDER BY size_gb DESC - 检查分区命名规律：
WRH$_ACTIVE_1234567890_0是标准格式，数字部分是DBID+SNAP_ID范围，末尾_0表示基础分区 - 别碰
WRH$_ACTIVE_SES_MXDB_MXSN这类特殊分区——它是内存映射伪分区，删了会报ORA-14125
安全清理：用 TRUNCATE PARTITION 而非 DROP
TRUNCATE PARTITION 是唯一推荐的在线清理方式，它不走回滚段、不产生大量 redo，且不影响其他分区和 AWR 功能：
- 语法必须带完整 schema：
ALTER TABLE sys.WRH$_ACTIVE_SESSION_HISTORY TRUNCATE PARTITION WRH$_ACTIVE_1234567890_0 - 执行前确认该分区无活跃快照依赖：
SELECT MIN(snap_id), MAX(snap_id) FROM dba_hist_snapshot WHERE dbid = 1234567890—— 若结果范围覆盖该分区，说明仍有历史报告引用，强行截断会导致ORA-13505 - 一次只截一个分区，观察空间释放效果和数据库负载；批量操作建议写脚本加
SLEEP间隔，避免 latch contention - 别漏掉索引和主键：它们也占空间。
WRH$_ACTIVE_SESSION_HISTORY_PK可能还占几 GB，需单独ALTER INDEX ... SHRINK SPACE
删完不缩容？SHRINK SPACE 和 RESIZE 得分开做
删掉快照只是标记为可重用，段高水位线还在，空间不会还给操作系统：
- 先更新统计信息：
EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SYS', cascade => TRUE)，否则后续查dba_segments可能不准 - 对表执行：
ALTER TABLE sys.WRH$_ACTIVE_SESSION_HISTORY ENABLE ROW MOVEMENT; ALTER TABLE sys.WRH$_ACTIVE_SESSION_HISTORY SHRINK SPACE CASCADE; - 物理文件收缩要更谨慎：
ALTER DATABASE DATAFILE '/u01/oradata/db/sysaux01.dbf' RESIZE 2g;必须先确认顶部有连续空闲块，否则会报错
最易被忽略的是：TRUNCATE PARTITION 后索引分区不会自动收缩，而 SHRINK SPACE 需要开启 ROW MOVEMENT 且锁表几秒——这两个动作不在同一条命令里完成，得手动补全，否则空间就“卡”在那儿不动了。
