SYSAUX表空间异常增长主因是AWR快照、优化器统计信息、统一审计及19c ASTS组件，需用v$sysaux_occupants定位Top 5占用组件，再针对性清理或调优。
sysaux表空间突然涨到90%以上，八成不是均匀增长，而是某几个组件在“偷偷吃内存”——最常背锅的是awr快照（wrh$_系列）、优化器统计信息（wri$_optstat）、审计（aud$unified）和19c新增的asts组件（如wri$_sqlset_plan_lines）。别急着加数据文件，先定位真凶。
查占用大户：用v$sysaux_occupants快速筛出Top 5组件
这个视图是SYSAUX的“住户清单”，比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/ADVISOR（SQL调优集/ASTS）、AUDSYS（统一审计）、OWB（如果用过数据仓库构建）、EM（OEM历史）、OPTIMIZER（统计信息） - 注意：
SM/ADVISOR在19.7默认开启，但19.8起已默认关闭；若看到它占几十GB，大概率就是WRI$_SQLSET_PLAN_LINES这类LOB表在作祟 - 如果
AUDSYS排前三，说明统一审计日志没清理，不能查AUD$，得看AUD$UNIFIED或AUDSYS.AUD$UNIFIED
清AWR数据：drop_snapshot_range不释放空间？补flush_awr和shrink space
dbms_workload_repository.drop_snapshot_range只删元数据和索引项，底层WRH$_表的数据行还在，空间不会立刻回收：
- 确认保留策略：
SELECT retention FROM dba_hist_wr_control;若返回604800（7天），但实际有30天快照，说明自动清理卡住了 - 删完快照后必须立刻执行：
EXEC dbms_workload_repository.flush_awr;—— 强制刷内存采样并触发MMON的段收缩逻辑 - 对单个膨胀严重的表（如
WRH$_ACTIVE_SESSION_HISTORY）可直接分区截断：ALTER TABLE wrh$_active_session_history TRUNCATE PARTITION <partition_name>;</partition_name> - 若表支持行移动，再做收缩：
ALTER TABLE wrh$_sql_plan SHRINK SPACE CASCADE;（需先ENABLE ROW MOVEMENT） - 避免用
DELETE或TRUNCATE TABLE整表清，会锁表、阻塞新快照写入
调统计信息保留期：改dbms_stats参数比删历史更治本
优化器统计信息历史（WRI$_OPTSTAT开头的表）长期积累也会撑大SYSAUX，尤其在频繁收集的库中：
- 查当前保留天数：
SELECT dbms_stats.get_prefs('STALE_PERCENT') FROM dual;和SELECT dbms_stats.get_prefs('PUBLISH') FROM dual; - 缩短历史保留（Oracle 12c+）：
EXEC dbms_stats.set_global_prefs('STATISTICS_LEVEL', 'TYPICAL');+EXEC dbms_stats.alter_stats_history_retention(7); - 手动清理旧统计信息：
EXEC dbms_stats.purge_stats(SYSDATE - 7);（保留最近7天） - 注意：
purge_stats不释放空间，后续仍需ANALYZE TABLE wri$_optstat_histhead_history COMPUTE STATISTICS;帮优化器识别空闲块 - 如果
WRI$_OPTSTAT_HISTGRM_HISTORY特别大，可能是直方图过多，考虑收集时加method_opt => 'FOR ALL COLUMNS SIZE AUTO'而非REPEAT
19c ASTS组件暴涨：关auto_sql_tuning_set并清关联表
Oracle 19.7引入的自动SQL调优集（ASTS）默认启用，WRI$_SQLSET_PLAN_LINES等表可能单个占60GB+，且不随AWR策略清理：
- 查状态：
SELECT client_name, status FROM dba_autotask_client WHERE client_name = 'auto sql tuning set'; - 在CDB和所有PDB中禁用：
EXEC dbms_auto_task_admin.disable(client_name => 'auto sql tuning set', operation => NULL, window_name => NULL); - 清理脚本（MOS官方推荐）：
DELETE FROM sys.wri$_sqlset_plan_lines WHERE created + <code>COMMIT; - 之后必须收缩：
ALTER TABLE wri$_sqlset_plan_lines SHRINK SPACE CASCADE;（LOB列需额外处理：ALTER TABLE wri$_sqlset_plan_lines MODIFY LOB (plan_line) (SHRINK SPACE);） - 19.8+升级后记得验证是否已默认关闭，否则下次RU升级又可能被打开
真正棘手的从来不是“怎么删”，而是删完空间不释放——因为Oracle的延迟清理机制依赖后台作业，而这些作业本身又可能被高负载或锁阻塞。所以每次清理后务必跟flush_awr、shrink space和gather_table_stats三连，缺一不可。
