V$SYSAUX_OCCUPANTS可快速定位SYSAUX表空间占用最高的功能模块，如SM/ADVISOR、AUDSYS、OPTIMIZER、SM/AWR等，其SPACE_USAGE_KBYTES字段直接反映各模块实时占用量，比查DBA_SEGMENTS更高效、语义更清晰。
直接看 V$SYSAUX_OCCUPANTS，它能立刻告诉你谁在吃空间，比查 DBA_SEGMENTS 快、准、语义清晰。
用 V$SYSAUX_OCCUPANTS 快速筛出 Top 5 占用组件
这个视图是 SYSAUX 的“住户清单”，字段 SPACE_USAGE_KBYTES 直接反映各功能模块的实时占用量。别一上来就扫全库段，先跑这句：
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（尤其 19.7 中默认开启的 ASTS）、AUDSYS（统一审计）、OPTIMIZER（统计信息顾问日志）、SM/AWR（AWR 元数据）。MOVE_PROCEDURE 为 NULL 表示该组件不支持迁移，只能清理或调优。
- 如果
SM/ADVISOR排第一且 GB 数异常高（比如 >10GB），大概率是WRI$_SQLSET_PLAN_LINES这类 LOB 表撑爆了 —— 这是 19.7 新增 ASTS 功能的典型症状 -
AUDSYS高居前三？说明审计策略太宽或未启用自动清理，不能查AUD$，得盯AUD$UNIFIED -
OPTIMIZER持续上涨？检查AUTO_STATS_ADVISOR_TASK是否失控，历史诊断日志堆积如山
查 AWR 相关膨胀时，必须同步看基线是否锁住快照
只删快照不等于释放空间。很多情况下 DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE 执行完，DBA_SEGMENTS 里 WRH$_* 表体积纹丝不动 —— 因为有 STATIC 或配置不当的 MOVING_WINDOW 基线钉住了快照。
先确认基线状态：
SELECT baseline_name, baseline_type, start_snap_id, end_snap_id, creation_time
FROM dba_hist_baseline_details
WHERE baseline_type IN ('STATIC', 'MOVING_WINDOW');
-
START_SNAP_ID极老（如半年前）而END_SNAP_ID仍很高 → 大量快照被锁定 -
MOVING_WINDOW的WINDOW_SIZE若远大于当前RETENTION（查DBA_HIST_WR_CONTROL），也会导致自动清理失效 - 删基线前务必查
DBA_HIST_BASELINE_TEMPLATE和LAST_USED_TIME，避免误删正在用于性能回溯的基线
查到大对象后，别急着 TRUNCATE TABLE 或 DELETE
对 WRH$_* 或 WRI$_* 类系统表，整表清会锁表、阻塞新快照写入，还可能触发 ORA-00604/ORA-1653。正确路径是分区级操作 + 物理收缩：
- 先确认表是否支持行移动：
ALTER TABLE wrh$_sql_plan ENABLE ROW MOVEMENT; - 按需截断单个分区：
ALTER TABLE wrh$_active_session_history TRUNCATE PARTITION WRH$_ACTIVE_4236113748_0; - 立即执行
EXEC DBMS_WORKLOAD_REPOSITORY.FLUSH_AWR;—— 这步强制唤醒 MMON，触发段收缩逻辑 - 再做物理空间回收：
ALTER TABLE wrh$_sql_plan SHRINK SPACE CASCADE;
注意：SHRINK SPACE 要求表启用了行移动，且不能在只读 PDB 或 NOLOGGING 模式下跳过重做日志（生产环境慎用 NOCOMPRESS）。
监控不能只靠人工查，得固化成巡检脚本
SYSAUX 异常膨胀往往有迹可循：某天 SM/ADVISOR 占用突增 300%，或 AUDSYS 日均增长翻倍。把下面三件事写进定时任务：
- 每日凌晨跑一次
V$SYSAUX_OCCUPANTS差值比对，对环比增长 >20% 的OCCUPANT_NAME发告警 - 每周检查
DBA_HIST_BASELINE_DETAILS，标记START_SNAP_ID超过 30 天的STATIC基线 - 每月执行
SELECT segment_name, bytes/1024/1024/1024 FROM dba_segments WHERE tablespace_name = 'SYSAUX' AND bytes > 1024*1024*1024 ORDER BY bytes DESC，抓出 >1GB 的冷对象
真正容易被忽略的是：SYSAUX 不可离线，所有操作都得在线完成；而很多清理动作（比如 SHRINK SPACE）会产生大量 undo 和临时段，高峰期执行可能拖慢业务 SQL 解析 —— 低峰期不是建议，是硬性前提。
