SYSTEM表空间爆满90%以上主因是AUD$审计表长期未清理，其默认位于SYSTEM且不自动分区或随用户删除而清理；应优先用DBMS_AUDIT_MGMT安全清理而非TRUNCATE，并检查audit_trail参数配置。
SYSTEM表空间突然告警：先查是不是审计数据在撑爆
oracle的system表空间爆满，90%以上不是因为业务表建错了位置，而是aud$（审计记录表）长期没清理。它默认就住在system里，且不走自动分区、不随drop user自动清理，日积月累就能把system塞到95%+。
实操建议：
- 立刻执行：
SELECT owner, segment_name, bytes/1024/1024 MB FROM dba_segments WHERE tablespace_name = 'SYSTEM' ORDER BY bytes DESC;
看前几行是不是AUD$或AUDIT$ - 确认审计是否开启：
SHOW PARAMETER audit_trail
如果返回DB或DB, EXTENDED，说明审计写入数据库，风险就在那儿 - 别急着删——
AUD$是基表，直接TRUNCATE可能破坏字典一致性；优先走官方清理路径
用DBMS_AUDIT_MGMT清理AUD$，而不是DELETE或TRUNCATE
Oracle 11gR2起提供DBMS_AUDIT_MGMT包专管审计数据生命周期，它能安全归档、压缩、清理，还能切换AUD$到非SYSTEM表空间。硬DELETE会锁表、阻塞审计写入，还可能触发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);
- 清理后务必手工回收空间：
ALTER TABLE aud$ MOVE TABLESPACE users;
再ALTER TABLE aud$ SHRINK SPACE（需行移动启用）
audit_trail=OS时，SYSTEM不会被AUD$撑爆，但要注意日志轮转
如果audit_trail设为OS，审计记录写进操作系统文件（如$ORACLE_HOME/rdbms/audit/），SYSTEM表空间本身不会因此膨胀。但容易忽略的是：这些OS文件没人管，磁盘照样会被打满，而且ORA-09925: Unable to write audit trail file会导致后续DML失败。
实操建议：
- 确认路径：
SHOW PARAMETER audit_file_dest
检查目录权限和磁盘剩余空间 - OS层必须配logrotate或定时脚本，比如保留最近7天：
/u01/app/oracle/admin/ORCL/adump/*.aud { daily rotate 7 compress missingok } - 切忌用
rm -f *.aud暴力清空——Oracle进程可能正往里面写，会触发写错或实例挂起 - 若已出现
ORA-09925，先停应用，清空部分旧文件，再重启监听或实例（视严重程度）
SYSTEM表空间真被业务对象误占了？迁移比收缩更稳妥
极少数情况是开发误把大表建在SYSTEM（比如忘了指定TABLESPACE，又没设用户默认表空间）。这时SYSTEM里会出现USER_TABLES、INDEXES等非系统对象。不能SHRINK，因为SYSTEM不支持段压缩；也不能MOVE系统对象，会破坏数据字典。
实操建议：
- 定位误建对象：
SELECT owner, segment_name, segment_type FROM dba_segments WHERE tablespace_name = 'SYSTEM' AND owner NOT IN ('SYS','SYSTEM','XDB','WMSYS'); - 迁移到正确表空间：
ALTER TABLE username.table_name MOVE TABLESPACE users;
（索引需重建：ALTER INDEX idx_name REBUILD TABLESPACE users;） - 迁移后检查依赖：
DBA_DEPENDENCIES中是否有失效对象，特别是物化视图日志或函数索引 - 禁止事后补救：立刻修改用户默认表空间，并在开发规范里加SQL审核规则，拦截
CREATE TABLE ... WITHOUT TABLESPACE
真正麻烦的从来不是清理动作本身，而是审计策略没对齐业务生命周期——比如金融系统要留180天审计，但DBA按默认90天清，结果出事回溯不到原始操作。时间窗口、保留依据、归档路径，这三个点漏掉任何一个，下次还会爆。
