v$sysaux_occupants可快速定位SYSAUX空间占用最高的功能模块，如SM/AWR、SM/OPTSTAT、SM/ADVISOR、AUDSYS、XDB等，避免仅查dba_segments导致的归因偏差。
查 v$sysaux_occupants 快速定位 top 占用模块
别翻 dba_segments 逐个算大小，v$sysaux_occupants 是 oracle 官方提供的“住户清单”，直接按功能模块聚合空间使用量，响应快、语义清。执行以下查询即可一眼看出谁在吃空间：
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/AWR：AWR 快照数据（WRH$_*表） -
SM/OPTSTAT：优化器统计信息历史（WRI$_OPTSTAT*） -
SM/ADVISOR：SQL 调优集或统计信息顾问（12.2–18c 中常见于WRI$_ADV_OBJECTS） -
AUDSYS：统一审计日志（AUD$UNIFIED） -
XDB：XML DB 相关对象（较少见，但若启用 XDB 功能可能突增）
为什么不能只看 dba_segments？
dba_segments 返回的是物理段（表、索引、LOB），但 SYSAUX 的膨胀往往由“逻辑功能模块”驱动——比如一个 SM/ADVISOR 模块背后可能是几十张表+索引+LOB 段，单独看某张 WRI$_ADV_OBJECTS 表大小，容易忽略它配套的索引和 LOB 段。而 v$sysaux_occupants 已做聚合，数值更贴近真实占用归因。
典型误判场景：
- 看到
WRH$_ACTIVE_SESSION_HISTORY占 30GB，就以为是 AWR；结果v$sysaux_occupants显示SM/ADVISOR占 52GB —— 真凶其实是统计信息顾问任务，不是 AWR - 发现
AUD$UNIFIED表不大，但AUDSYS在v$sysaux_occupants排前三 —— 说明审计日志被压缩存储或用了分区策略，物理段名不直观
SM/ADVISOR 占比高时要特别注意版本和参数
在 12.2.0.1–18.3 中，AUTO_STATS_ADVISOR_TASK 默认开启且 EXECUTION_DAYS_TO_EXPIRE 设为 UNLIMITED，导致 WRI$_ADV_OBJECTS 等表持续增长。此时：
- 确认任务状态：
SELECT task_name, status FROM dba_advisor_tasks WHERE advisor_name = 'Statistics Advisor'; - 检查过期策略：
SELECT parameter_name, parameter_value FROM dba_advisor_parameters WHERE task_name = 'AUTO_STATS_ADVISOR_TASK' AND parameter_name = 'EXECUTION_DAYS_TO_EXPIRE'; - 若值为
UNLIMITED，需手动清理并重设：EXEC dbms_stats.alter_stats_history_retention(7);+EXEC dbms_stats.purge_stats(SYSDATE-7);
注意：19.8+ 已默认关闭该任务，升级后会自然缓解。
查完 v$sysaux_occupants 后下一步做什么？
拿到 top 占用模块后，不要直接删表或 truncate。先验证它是否还在活跃写入：
- 对
SM/AWR：查dba_hist_wr_control确认retention是否生效，再查dba_hist_snapshot看快照是否堆积 - 对
SM/OPTSTAT：运行SELECT dbms_stats.get_stats_history_retention FROM dual;，再查dba_tab_statistics的 last_analyzed 时间分布 - 对
SM/ADVISOR：必须结合dba_advisor_log看最近是否有失败/卡住的任务
最常被跳过的一步：确认 move_procedure 列是否有值。如果有（如 DBMS_STATS.MOVE_STATS），说明 Oracle 提供了官方迁移/清理入口，优先调用它，而不是手工 drop 或 truncate。
