应直接查询v$sysaux_occupants视图定位SYSAUX占用大户，因其按功能模块聚合统计、响应快、归因准；执行SELECT occupant_name, ROUND(space_usage_kbytes/1024/1024, 2) AS gb, schema_name, move_procedure FROM v$sysaux_occupants WHERE space_usage_kbytes > 0 ORDER BY space_usage_kbytes DESC。
SYSAUX表空间爆满不是“加数据文件就能扛过去”的问题，盲目扩容只会掩盖失控的自动任务；真正要做的，是快速定位占用主力、安全清理非业务元数据，并阻断后续膨胀源。
查清谁在吃掉SYSAUX空间：用V$SYSAUX_OCCUPANTS看组件级分布
别一上来就扫DBA_SEGMENTS，先看Oracle自己提供的“住户清单”，它能直接告诉你空间被哪些系统组件瓜分：
-
V$SYSAUX_OCCUPANTS中SM/ADVISOR（统计信息顾问）或SM/AWR（自动工作负载仓库）排前三，基本锁定根因 -
AUDSYS占比高说明统一审计日志未清理，但19c+默认不启用，优先级低于AWR和ADVISOR -
space_usage_kbytes为0的条目表示该组件未实际写入数据，可忽略 - 注意
MOVE_PROCEDURE列——如果值为NULL，说明该组件不支持在线迁移，清理需更谨慎
清理WRI$_ADV_OBJECTS：删掉统计顾问任务而非手动删表
当V$SYSAUX_OCCUPANTS显示SM/ADVISOR占大头，对应底层就是WRI$_ADV_OBJECTS表及其索引。这不是普通业务表，不能TRUNCATE或DROP，必须走官方接口：
- 用
SYS或SYSDBA执行：DBMS_STATS.DROP_ADVISOR_TASK('AUTO_STATS_ADVISOR_TASK') - 该操作会连带清除所有历史诊断记录，释放几十GB空间，且不影响日常
DBMS_STATS.GATHER_*任务 - 执行后不会立刻释放空间，需等SMON进程完成延迟清理，期间表空间使用率数字可能暂时不变
- 若报错
ORA-20000: Unable to drop advisor task，说明有活跃会话正在访问该任务，需先查V$SESSION杀掉相关会话
收缩WRH$系列表：用TRUNCATE PARTITION而非DELETE
AWR数据（如WRH$_ACTIVE_SESSION_HISTORY）通常以分区表存在，DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE只是逻辑删除，留大量碎片。要真正降高水位线，必须物理截断旧分区：
- 先查最老快照时间：
SELECT MIN(snap_id), MAX(snap_id) FROM dba_hist_snapshot - 再定位具体分区名：
SELECT partition_name FROM dba_tab_partitions WHERE table_name = 'WRH$_ACTIVE_SESSION_HISTORY' AND partition_name LIKE 'WRH$_ACTIVE%' - 对已过期分区执行：
ALTER TABLE WRH$_ACTIVE_SESSION_HISTORY TRUNCATE PARTITION WRH$_ACTIVE_1234567890_1234 - 注意：不能对当前活跃分区（如
WRH$_ACTIVE_1234567890_9999）操作，否则中断AWR采集 - 多个大表（
WRH$_SQLSTAT、WRH$_EVENT_HISTOGRAM）需逐个处理，顺序无关
预防复发：关掉自动顾问 + 调整AWR保留策略
清理完只是止血，不改配置等于没治。两个动作必须做：
- 永久禁用冗余顾问：
EXEC DBMS_AUTO_TASK_ADMIN.DISABLE(client_name => 'auto optimizer stats collection', operation => NULL, window_name => NULL)—— 这比删AUTO_STATS_ADVISOR_TASK更彻底，防止它被重建 - 收紧AWR保留：运行
EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(retention => 86400)（单位秒，此处设1天），默认8天太长，尤其在高负载库上 - 检查是否启用了
STATISTICS_LEVEL = ALL：若非必要调试，应设为TYPICAL，避免生成过多ASH细节 - 切记：所有
DBMS_*包调用都需SYS权限，且部分操作在RAC环境需在所有实例执行
最易被忽略的是清理后的空间回收延迟——TRUNCATE PARTITION后，dba_segments.bytes立即下降，但dba_free_space可能几小时后才更新，监控告警阈值别设太激进；另外，19c中AUDSYS若真占大头，不能直接删，得用DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL，走错路径会锁死审计功能。
