aud$表撑爆system表空间是oracle 11g生产库中system异常增长最常见、最确定的原因；须先查dba_segments确认其占用，再验证audit_trail参数，严禁truncate，必须用dbms_audit_mgmt初始化、设归档时间、清理，并迁移至专用表空间。
aud$ 表在 system 表空间中撑爆了，就是最常见、最确定的原因。别绕弯子查别的，先确认它是不是真凶。
怎么快速确认 AUD$ 是不是元凶
直接查占用最大的段，用证据说话，不是猜：
- 运行
SELECT owner, segment_name, segment_type, bytes/1024/1024/1024 GB FROM dba_segments WHERE tablespace_name = 'SYSTEM' ORDER BY bytes DESC FETCH FIRST 5 ROWS ONLY - 如果第一行是
AUD$（OWNER为SYS），基本可以收工了 - 再验证审计是否开着：
SHOW PARAMETER audit_trail，返回DB或DB, EXTENDED就坐实了；返回NONE或FALSE才跳过这步
千万别直接 TRUNCATE TABLE aud$
硬 truncate 在 Oracle 11g 及以上版本会锁表、阻塞新审计写入，甚至触发 ORA-00600 内部错误。必须走官方清理路径：
- 先初始化（只做一次）：
BEGIN DBMS_AUDIT_MGMT.INIT_CLEANUP(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD); END;—— 若报ORA-46262，说明没初始化，必须先跑这句 - 设保留窗口（例如 90 天）：
EXEC DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, last_archive_time => SYSTIMESTAMP - 90) - 执行清理：
EXEC DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, cleanup_only => TRUE) - 注意：清理完数据还在
SYSTEM里，只是被标记为可回收，空间不会自动释放
迁移 AUD$ 出 SYSTEM 才算真正解决
清理只是“清数据”，迁移才是“清根源”。否则下次又涨回来：
- 建专用表空间（如
AUDIT_TBS），确保自动扩展合理（比如NEXT 100M，别设成1G） - 迁移前开行移动：
ALTER TABLE aud$ ENABLE ROW MOVEMENT - 迁移表：
ALTER TABLE aud$ MOVE TABLESPACE audit_tbs - 查
dba_indexes找AUD$的索引名（通常是I_AUD1），重建索引：ALTER INDEX i_aud1 REBUILD TABLESPACE audit_tbs - 迁移后建议收缩：
ALTER TABLE aud$ SHRINK SPACE - 迁移后验证：
SELECT tablespace_name FROM dba_tables WHERE table_name = 'AUD$'
真正麻烦的不是清理动作本身，而是清理后不迁移——等于给定时炸弹换了个电池。另外，IDL_UB1$、SOURCE$、用户误建对象这些次常见原因，只有在排除 AUD$ 后才值得深挖。
