AUD$默认在SYSTEM表空间且审计未清理导致空间暴涨，须用DBMS_AUDIT_MGMT官方包清理并迁移表至专用表空间，同时排查非SYS用户对象及调度日志误驻SYSTEM。
AUD$ 表默认落在 SYSTEM 表空间，且 Oracle 11gR2 起默认启用 audit_trail = DB，审计记录持续写入、从不自动清理——这就是暴涨的直接原因。
查确认：AUD$是不是真在SYSTEM里撑着？
别猜，直接查前几大的段：
SELECT owner, segment_name, bytes/1024/1024 MB FROM dba_segments WHERE tablespace_name = 'SYSTEM' ORDER BY bytes DESC;
如果第一行是 AUD$（且 OWNER 是 SYS），基本不用往下看了。
再确认审计是否开着：
SHOW PARAMETER audit_trail
返回 DB 或 DB, EXTENDED 就是它；返回 NONE 或 FALSE 可跳过这步。
-
AUD$占比超 90% 是常态，不是配置错，也不是 SQL 写得烂，就是日积月累没管 - 哪怕只开
BY SESSION审计，长期运行后仍会达几十 GB 级别 - 注意：
FGA_LOG$也可能一起躺在SYSTEM里，一并查
别 TRUNCATE TABLE aud$ —— 锁表+ORA-00600 风险高
硬清 AUD$ 表会阻塞新审计写入，还可能触发内部错误。Oracle 11gR2 起必须走官方包清理路径：
- 先初始化（只做一次）：
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)
注意：清理完 AUD$ 数据还在 SYSTEM 里，只是被标记为可回收——物理空间不会自动释放。
挪走 AUD$ 表本身：MOVE + SHRINK 才算收尾
清理数据只是第一步，AUD$ 表结构仍占着 SYSTEM 的段头和 HWM（高水位线）。必须迁移：
- 先建好目标表空间（如
USERS或专用的AUDIT_TBS） - 执行迁移：
ALTER TABLE aud$ MOVE TABLESPACE users;
- 收缩空间（需先启用行移动）：
ALTER TABLE aud$ ENABLE ROW MOVEMENT; ALTER TABLE aud$ SHRINK SPACE;
- 同步更新索引：
ALTER INDEX i_aud1 REBUILD TABLESPACE users;
（查索引名用SELECT index_name FROM dba_indexes WHERE table_name = 'AUD$'）
不挪表，下次清理后空间还会涨回来——因为新插入仍发生在原位置。
顺手检查非系统用户对象和 JOB 日志是否误驻 SYSTEM
审计不是唯一元凶。两个容易被忽略的“共犯”：
- 查有没有用户对象误建在
SYSTEM：SELECT owner, segment_name FROM dba_segments WHERE tablespace_name = 'SYSTEM' AND owner NOT IN ('SYS', 'SYSTEM')若有结果，立刻改该用户的默认表空间，并迁移对象 - 查调度日志是否也挤进来了：
SELECT owner, segment_name, tablespace_name FROM dba_segments WHERE segment_name IN ('JOB_LOG', 'SCHEDULER$_JOB_LOG') AND owner = 'SYS'如果tablespace_name是SYSTEM，说明配置异常，应通过DBMS_SCHEDULER相关过程重定向或重建
真正棘手的是：这些对象往往混在一起增长，单看 AUD$ 占比下降了，但总空间没降——因为 IDL_UB1$ 或 SOURCE$ 正在悄悄膨胀。每次清理前，务必全量扫描 dba_segments，别只盯一个名字。
