sysaux 表空间自动增长过快主因是 awr 快照、auto_stats_advisor_task 和统一审计等组件写入未及时清理；需用 v$sysaux_occupants 定位占用源，执行 flush_awr、drop_advisor_task、shrink space 等操作并验证效果。
SYSAUX 表空间在 Oracle 11g 中自动增长过快，基本不是“自动”行为，而是几个默认开启、但清理机制不健全的功能在持续写入且未被及时回收——最常踩坑的是 AWR 快照、AUTO_STATS_ADVISOR_TASK 和统一审计（虽 11g 默认未启用，但若手动开启则同样落 SYSAUX）。
查清楚谁在吃空间：优先用 v$sysaux_occupants 定位组件
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：对应WRH$_系列快照表，11g 默认保留 8 天，但若快照未真正 purge（比如有基线锁定、或 MMON 卡住），实际保留远超该值 -
SM/ADVISOR：11g 已含AUTO_STATS_ADVISOR_TASK，其日志表WRI$_ADV_OBJECTS无自动清理逻辑，长期运行后可涨到数 GB -
AUDSYS：仅在启用了统一审计时出现；11g 默认是传统审计（AUD$在SYSTEM），但如果手动切了统一审计，日志就进SYSAUX -
OPTIMIZER：统计信息历史（WRI$_OPTSTAT表）积累过多，尤其在频繁dbms_stats.gather_table_stats的场景下
drop_snapshot_range 删了快照却不释放空间？必须补 flush_awr
dbms_workload_repository.drop_snapshot_range 只删元数据和索引，底层 WRH$_ 表的数据行仍物理存在，空间不会回收：
确认当前保留策略：SELECT retention FROM dba_hist_wr_control; —— 11g 默认返回 691200 秒（8 天）
删完快照后务必立刻执行：EXEC dbms_workload_repository.flush_awr;
这一步强制触发 MMON 的段收缩逻辑。否则你看到的 “已删快照” 只是假象，WRH$_ACTIVE_SESSION_HISTORY 等大表仍占着空间。
若某分区特别膨胀，可直接截断：ALTER TABLE wrh$_active_session_history TRUNCATE PARTITION <partition_name>;</partition_name>
注意：TRUNCATE PARTITION 比整表 DELETE 安全，不锁全表，也不压爆 undo。
WRI$_ADV_OBJECTS 占几十 GB？直接删掉 AUTO_STATS_ADVISOR_TASK
这个任务在 11g 是默认启用的，但它的日志表 WRI$_ADV_OBJECTS + 3 个索引可轻松吃掉 10+ GB，且无自动清理：
它只用于生成统计信息体检报告，业务完全不需要，删掉不影响自动统计收集。
以 SYS 用户执行：
DECLARE v_tname VARCHAR2(100); BEGIN v_tname := 'AUTO_STATS_ADVISOR_TASK'; DBMS_STATS.DROP_ADVISOR_TASK(v_tname); END; /
执行后，WRI$_ADV_OBJECTS 表数据会被清空（非立即 drop 表，而是逻辑清理），后续不再写入。
如果版本是 11.2.0.4 且打过某些补丁，可能遇到 BUG 导致 delete_expired_tasks 不生效——此时 DROP_ADVISOR_TASK 是最稳的兜底方案。
别忽略 WRH$_SQL_PLAN 和直方图残留
WRH$_SQL_PLAN 在 11g 中默认按 SQL ID + PLAN_HASH_VALUE 去重，但若大量 SQL 使用绑定变量且计划多变，仍会持续膨胀：
查行数：SELECT COUNT(*) FROM sys.wrh$_sql_plan; —— 若超千万级，需干预
它不响应 AWR 保留策略，得手动收缩：ALTER TABLE wrh$_sql_plan SHRINK SPACE CASCADE;
前提是先启用行移动：ALTER TABLE wrh$_sql_plan ENABLE ROW MOVEMENT;
另外，频繁收集带 method_opt => 'FOR ALL COLUMNS SIZE AUTO' 的直方图，会导致 WRI$_OPTSTAT_HISTGRM_HISTORY 爆炸式增长——建议改用 SIZE SKEWONLY 或定期清理历史：EXEC dbms_stats.purge_stats(SYSDATE - 30);
真正麻烦的从来不是“怎么删”，而是删完之后没人检查 flush_awr 是否真跑成功、没人确认 SHRINK SPACE 是否被阻塞、也没人盯住 DBA_AUTOTASK_CLIENT 里有没有残留的 advisor 任务开着。这些细节卡住，SYSAUX 就永远在“刚清理完又涨回来”的循环里。
