应直接查询v$sysaux_occupants视图定位sysaux占用大户，因其按功能模块聚合统计、响应快、归因准，避免依赖dba_segments导致的误判；执行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 各组件占用：直接用 v$sysaux_occupants
别翻 dba_segments 算表大小，v$sysaux_occupants 是 Oracle 官方提供的聚合视图，按功能模块统计空间，响应快、归因准、不依赖段统计刷新延迟。
- 必须以
SYS或SYSDBA身份执行 - 结果单位是 KB，建议转成 GB 更直观
- 只返回
space_usage_kbytes > 0的活跃模块，空模块不显示 - 字段
move_procedure表示该模块是否支持迁移（如DBMS_AW.MOVE_AWMETA），但多数模块不建议随意移动
执行这个查询：
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;
SM/ADVISOR 占高？重点盯 WRI$_SQLSET_PLAN_LINES 和自动任务
SM/ADVISOR 在 12.2–19.7 版本中常因 AUTO_STATS_ADVISOR_TASK 持续运行且未设过期策略而暴增，背后主要是 LOB 类型的 WRI$_SQLSET_PLAN_LINES 表撑起来的，不是 AWR 本身。
- 先确认任务状态：
SELECT task_name, status FROM dba_advisor_tasks WHERE advisor_name = 'Statistics Advisor'; - 检查过期参数：
SELECT parameter_value FROM dba_advisor_parameters WHERE task_name = 'AUTO_STATS_ADVISOR_TASK' AND parameter_name = 'EXECUTION_DAYS_TO_EXPIRE';—— 若为UNLIMITED就是根源 - 清理前必须停任务：
EXEC DBMS_ADVISOR.DELETE_TASK('AUTO_STATS_ADVISOR_TASK'); - 再收缩历史：
EXEC dbms_stats.alter_stats_history_retention(7); EXEC dbms_stats.purge_stats(SYSDATE-7);
AUDSYS 排前三？说明统一审计日志没清理
AUDSYS 占用高 ≠ AUD$ 表大，它对应的是 AUD$UNIFIED，物理段在 SYSAUX 里但 owner 是 AUDSYS。不能查 SYS.AUD$，也不能 TRUNCATE 基表。
- 确认是否启用统一审计：
SHOW PARAMETER audit_trail;返回XML或XML, EXTENDED即启用 - 初始化清理框架：
BEGIN DBMS_AUDIT_MGMT.INIT_CLEANUP(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED); END; - 执行清理：
EXEC DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED, cleanup_only => TRUE); - 清理后需手工回收空间：
ALTER TABLE audsys.aud$unified MOVE TABLESPACE sysaux;（或迁到其他表空间）+ALTER TABLE audsys.aud$unified SHRINK SPACE;（需先ENABLE ROW MOVEMENT）
为什么 dba_segments 容易误判？
dba_segments 只告诉你“哪张表占多少空间”，但 SYSAUX 膨胀本质是逻辑模块驱动的——比如一个 SM/ADVISOR 模块可能包含十几张表 + 对应索引 + LOB 段，单独看 WRI$_ADV_OBJECTS 表大小，会漏掉它的 LOB 段和二级索引。
-
v$sysaux_occupants已做跨段聚合，数值更贴近真实归因 -
dba_segments对分区表、LOB 列估算不准，且统计可能滞后几分钟 - 典型误判：
WRH$_ACTIVE_SESSION_HISTORY显示 30GB，但v$sysaux_occupants中SM/ADVISOR占 52GB —— 真凶是统计顾问，不是 AWR
真正要动手清理时，得回到模块级逻辑：看它是 AWR、审计、还是顾问任务失控；光盯着物理段名，容易修错地方。
