不能直接TRUNCATE SYS.AUD$，必须用DBMS_AUDIT_MGMT四步闭环清理：初始化、设归档时间戳、逻辑清理、SHRINK SPACE；还需迁移出SYSTEM表空间并注意统一审计与批处理限制。
不能直接 TRUNCATE SYS.AUD$，否则空间不释放、高水位线卡死、后续清理失效，甚至触发 ORA-46267 报错。
确认 AUD$ 是不是 SYSTEM 表空间的“爆满元凶”
先别动手删，得验证是不是它在撑爆 SYSTEM：
- 查表位置：
SELECT owner, table_name, tablespace_name FROM dba_tables WHERE table_name = 'AUD$'—— 如果tablespace_name是SYSTEM，就是它 - 看占多大：
SELECT segment_name, bytes/1024/1024 MB FROM dba_segments WHERE segment_name = 'AUD$' AND owner = 'SYS' - 比总量：
SELECT tablespace_name, round((bytes - free_bytes)/1024/1024) used_mb FROM (SELECT tablespace_name, sum(bytes) bytes FROM dba_data_files WHERE tablespace_name = 'SYSTEM' GROUP BY tablespace_name), (SELECT tablespace_name tablespace_name2, sum(bytes) free_bytes FROM dba_free_space WHERE tablespace_name = 'SYSTEM' GROUP BY tablespace_name) WHERE tablespace_name = tablespace_name2—— 若AUD$占 SYSTEM 总用量 30% 以上，基本可锁定
必须用 DBMS_AUDIT_MGMT 四步闭环清理
Oracle 11gR2 起强制要求走这套路径，跳过任意一步都会导致清理无效或空间不回收：
- 初始化（仅首次需运行）：
BEGIN sys.DBMS_AUDIT_MGMT.init_cleanup(audit_trail_type => sys.DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, default_cleanup_interval => 24); END; - 设归档时间戳（关键！决定删哪些）：
BEGIN sys.DBMS_AUDIT_MGMT.set_last_archive_timestamp(audit_trail_type => sys.DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, last_archive_time => SYSTIMESTAMP - 7); END;—— 这里- 7表示保留最近 7 天 - 执行逻辑清理：
BEGIN sys.DBMS_AUDIT_MGMT.clean_audit_trail(audit_trail_type => sys.DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, use_last_arch_timestamp => TRUE); END;——use_last_arch_timestamp => TRUE必须显式写，否则忽略上一步 - 检查效果：
SELECT COUNT(*) FROM sys.aud$数量应下降；但dba_segments中该段大小不变 —— 这是正常现象，只删行，未收缩段
清理后必须手动 SHRINK + MOVE 才能真正释放空间
clean_audit_trail 只做逻辑删除，物理空间不会返还给表空间。不操作这步，下次照样爆满：
- 先开行移动：
ALTER TABLE sys.aud$ ENABLE ROW MOVEMENT - 再收缩段：
ALTER TABLE sys.aud$ SHRINK SPACE CASCADE—— 注意：若AUD$含 LOB 字段（如SQLTEXT、SQLBIND），需额外对 LOB 段单独 MOVE，否则 SHRINK 会失败 - 强烈建议迁移出 SYSTEM：
BEGIN DBMS_AUDIT_MGMT.set_audit_trail_location(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, audit_trail_location_value => 'AUDIT_TBS'); END;—— 新建专用表空间（如AUDIT_TBS）后再迁移，避免反复踩坑
容易被忽略的三个硬约束
很多 DBA 卡在这三点上，以为清理完了，结果两天后又告警：
- 统一审计（
V$OPTION中Unified Auditing=TRUE）下，AUD$仅存传统审计日志，清它不影响统一审计，但DBMS_AUDIT_MGMT.clean_audit_trail默认不处理统一审计表（UNIFIED_AUDIT_TRAIL），需另起一套清理逻辑 -
audit_trail=DB是默认开启状态，所有清理都是临时止血；长期方案仍是ALTER SYSTEM SET audit_trail = NONE SCOPE=SPFILE并重启 —— 生产环境若不能重启，至少关掉高频审计项，比如：NOAUDIT SESSION WHENEVER SUCCESSFUL、NOAUDIT SESSION BY DBSNMP -
DBMS_AUDIT_MGMT清理受DB AUDIT CLEAN BATCH SIZE参数控制（查dba_audit_mgmt_config_params），默认 10000；若单次清理量超限，会分批执行，但日志不显式提示，容易误判为“没清理成功”
