确认AUD$表撑爆SYSTEM表空间后，应先用TRUNCATE TABLE SYS.AUD$快速释放空间（不走undo、瞬时生效），再执行ALTER TABLESPACE SYSTEM COALESCE回收碎片；若需彻底禁用，须设audit_trail=NONE并重启实例。
system表空间剩余空间不足，99%以上情况是 aud$ 表撑爆的——它默认存审计日志，而 oracle 11gr2 起 audit_trail 默认值就是 db，只要没关，sys.aud$ 就在 system 表空间里持续写入，不清理就只涨不缩。
怎么确认是 AUD$ 占满 SYSTEM？
别猜，直接查：
- 先看 SYSTEM 剩多少：
SELECT tablespace_name, ROUND(SUM(bytes)/1024/1024/1024, 2) "GB" FROM dba_free_space WHERE tablespace_name = 'SYSTEM' GROUP BY tablespace_name;—— 如果返回0.01或空，基本坐实了 - 再看谁占得最多：
SELECT segment_name, segment_type, owner, ROUND(bytes/1024/1024/1024, 2) "GB" FROM dba_segments WHERE tablespace_name = 'SYSTEM' ORDER BY bytes DESC FETCH FIRST 5 ROWS ONLY;—— 如果第一行是AUD$且大于 1GB，就是它 - 顺手验证审计是否开着：
SELECT value FROM v$parameter WHERE name = 'audit_trail';—— 返回DB、DB, EXTENDED或XML都算开启；返回NONE或FALSE可跳过后续清理步骤
TRUNCATE TABLE SYS.AUD$ 为什么比 DELETE 更合适？
DELETE FROM SYS.AUD$ 看似直观，但实际会触发大量 undo、归档和锁等待，尤其当表有几千万行时，可能卡住数小时，还可能因事务过大导致 ORA-01555；而 TRUNCATE 是 DDL 操作，不走 undo，不生成归档，瞬间释放空间，且重置高水位线（HWM）。
- 执行前必须用
sqlplus / as sysdba登录，普通 DBA 权限不够 - 确保数据库处于 OPEN 状态（不是 MOUNT），否则报 ORA-01109
- 执行后立即生效：
TRUNCATE TABLE SYS.AUD$;—— 注意不能加WHERE，也不支持PURGE选项 - 如果遇到 ORA-00604 / ORA-01653 报错连不上库，说明已无法执行任何 SQL，只能先扩文件或关审计再重试
关审计（audit_trail=NONE）要不要重启？
要。因为 audit_trail 是静态参数（ISPSES 为 FALSE），改完 scope=spfile 后必须重启实例才生效。不重启的话，哪怕你执行了 ALTER SYSTEM SET audit_trail = NONE SCOPE=SPFILE;，下次登录仍会继续往 AUD$ 写。
- 重启前建议先
TRUNCATE SYS.AUD$，避免重启过程中残留日志又占空间 - 重启后立刻验证：
SELECT value FROM v$parameter WHERE name = 'audit_trail';必须返回NONE - 如果业务强依赖审计（如等保、SOX），不要直接关，改用统一审计 + 定期清理
UNIFIED_AUDIT_TRAIL（它在 SYSAUX，不影响 SYSTEM）
清理后空间没回来？注意这几个隐藏坑
TRUNCATE 成功不代表空间立刻“可用”——Oracle 的空间管理有延迟和边界限制：
-
AUD$所在段可能被分配在 SYSTEM 表空间的非连续区域，TRUNCATE后需手动回收碎片：ALTER TABLESPACE SYSTEM COALESCE; - 如果 SYSTEM 数据文件
AUTOEXTENSIBLE关闭且已到上限，即使清空了表，dba_free_space仍可能查不到新空闲块，得先ALTER DATABASE DATAFILE '/path/to/system01.dbf' AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED; - 某些版本（如 12.1.0.2）中，
TRUNCATE后首次查询dba_free_space可能延迟数分钟才更新，别急着重复操作 - 如果用了 Oracle Managed Files（OMF），文件路径不直观，查
dba_data_files时注意FILE_NAME是别名，真实路径得看V$DATAFILE
