用v$sysaux_occupants可快速定位SYSAUX空间占用大户，比dba_segments更及时准确；重点关注SM/ADVISOR、AUDSYS、OPTIMIZER等组件，执行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。
查SYSAUX里谁在偷偷吃空间：用v$sysaux_occupants比dba_segments更快
直接跑 v$sysaux_occupants 是定位sysaux膨胀源头最省力的方式，它不依赖段统计延迟，也不受lob缓存影响，能立刻反映各功能模块的真实占用。dba_segments有时会滞后几分钟，且对分区表、lob列的估算不准。
执行：
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（19c ASTS相关）、AUDSYS（统一审计）、OPTIMIZER（统计信息历史）、EM（OEM残留）、OWB（已弃用但可能残留） -
SM/ADVISOR占几十GB？大概率是WRI$_SQLSET_PLAN_LINES这类LOB表撑的，不是AWR本身 -
AUDSYS排前三？说明AUD$UNIFIED没清理，不能查AUD$，得盯AUDSYS.AUD$UNIFIED
SYSTEM表空间突然涨满：先确认是不是AUD$在作祟
SYSTEM爆满90%以上，八成就是 AUD$ 表没管——它默认就躺在SYSTEM里，不自动分区、不随用户删除而清理，日积月累就能塞爆。
别急着 TRUNCATE TABLE aud$。Oracle 11gR2起明确不推荐直接操作基表，风险包括字典不一致、ORA-00600、审计写入阻塞。
- 先确认审计是否启用：
SHOW PARAMETER audit_trail；返回DB或DB, EXTENDED就是真凶 - 优先走官方路径：
DBMS_AUDIT_MGMT初始化并清理，例如：BEGIN DBMS_AUDIT_MGMT.INIT_CLEANUP(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD); END;
- 设归档时间戳后执行清理：
EXEC DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, cleanup_only => TRUE) - 清理完必须手工回收：
ALTER TABLE aud$ MOVE TABLESPACE users+ALTER TABLE aud$ SHRINK SPACE（需先ENABLE ROW MOVEMENT）
三方组件埋雷：OWB、EM、LogMiner段长期驻留SYSAUX
很多老系统装过OWB（Warehouse Builder）、OEM（Enterprise Manager）、或开过LogMiner做CDC/逻辑复制，这些组件卸载不干净，相关段就卡在SYSAUX里不动，空间只增不减。
查 dba_segments 时重点扫这些前缀：
-
OWB_开头的表（如OWB_PROCESS_FLOW）→ 卸载OWB后未清空，需手动DROP USER owbsys CASCADE（确认无依赖） -
MGMT_/EM_开头的对象 → OEM历史残留，检查em_repository是否还在运行，停服务后删对应schema -
LOGMNRC_/LOGMNR_开头的段 → LogMiner日志未关闭或未调用DBMS_LOGMNR.END_LOGMNR，查V$LOGMNR_CONTENTS是否有活跃会话 - 注意：这些对象通常 owner 是
OWBSYS、DBSNMP、CTXSYS等，不是SYS，容易被忽略
AWR快照删了但空间不释放：flush_awr和shrink_space缺一不可
dbms_workload_repository.drop_snapshot_range 只删元数据和索引项，WRH$_表里的实际数据行还在，空间不会回收——这不是bug，是Oracle的延迟清理机制。
必须补两步，否则白删：
- 删完立刻执行：
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（先ALTER TABLE ... ENABLE ROW MOVEMENT） - 严禁用
DELETE FROM wrh$_xxx或整表TRUNCATE，会锁表、阻塞新快照写入，且undo暴涨
真正麻烦的从来不是“怎么删”，而是删完之后没人记得去 SHRINK SPACE 或 MOVE TABLESPACE —— 那些空闲块就一直躺在那里，等着下次告警再响一遍。
