SYSTEM表空间爆满导致ORA-02002登录失败，根因为ORA-00604与ORA-01653，AUD$表常占SYSTEM 70%以上空间；应先查AUD$大小及审计策略，再通过FLUSH_UNIFIED_AUDIT_TRAIL或DELETE+COMMIT清理，而非直接扩容。
SYSTEM表空间爆满导致ORA-02002登录失败
这不是审计功能本身的问题，而是审计写入动作触发了SYSTEM表空间内递归SQL执行，而此时SYSTEM已无空间分配新区（extent）。ORA-02002只是表象，ORA-00604 + ORA-01653才是根因。你连sqlplus / as sysdba都卡住，说明SYSTEM连基础字典操作都撑不住了——必须立刻干预，不能等应用重启或重试。
先确认是否真被AUD$表撑满
别急着扩文件。很多情况下，SYS.AUD$表占了SYSTEM 70%以上空间，尤其开了AUDIT SESSION又没清理时。用以下语句快速验证：
SELECT bytes/1024/1024 AS mb, owner, segment_name FROM dba_segments WHERE tablespace_name = 'SYSTEM' AND segment_name = 'AUD$';
如果返回值 > 2000 MB，基本可锁定问题源。再查审计策略：
-
show parameter audit_trail—— 若为DB，说明审计日志存库内 -
select count(*) from aud$—— 看记录量级（千万级以上就危险） -
select action_name, count(*) from dba_audit_trail group by action_name order by 2 desc—— 确认是不是LOGON/LOGOFF刷屏式写入
紧急清理AUD$比扩容更安全有效
在SYSTEM已满、无法执行常规DDL时，TRUNCATE TABLE aud$会失败（需要空间建回滚段）。正确做法是：
- 用
ALTER SYSTEM CHECKPOINT强制写盘，减少活动事务对SYSTEM的压力 - 执行
BEGIN DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL; END;（仅适用于统一审计） - 对传统审计，改用
DELETE FROM aud$ WHERE rownum 分批删，每删完一次<code>COMMIT，避免大事务撑爆UNDO - 删完后立即
ALTER SYSTEM ARCHIVE LOG CURRENT并ALTER DATABASE BACKUP CONTROLFILE TO TRACE留痕
注意：NOAUDIT SESSION只能阻止新增，不能释放已有空间；DROP TABLE aud$绝对禁止——这是数据字典核心表。
扩容前必须检查AUTOEXTEND和磁盘余量
盲目ALTER DATABASE DATAFILE ... AUTOEXTEND ON可能让单个数据文件突破OS文件大小限制（如ext4单文件上限16TB，但Oracle小文件表空间实际限于128GB）。操作前务必确认：
SELECT file_name, autoextensible, maxbytes/1024/1024 AS max_mb FROM dba_data_files WHERE tablespace_name = 'SYSTEM'- 对应文件所在磁盘剩余空间：
df -h /u01/oracle/oradata/orcl/（路径按实际替换） - 若
maxbytes已接近磁盘上限，优先用ADD DATAFILE而非RESIZE
真正要动手时，只加一个500MB起步的新文件：ALTER TABLESPACE SYSTEM ADD DATAFILE '/path/to/system02.dbf' SIZE 500M AUTOEXTEND ON NEXT 50M MAXSIZE 4G。别设UNLIMITED——失控增长比空间不足更难收场。
SYSTEM表空间不是普通用户空间，任何操作都牵一发而动全身。清理AUD$后，一定要查dba_segments里还有没有其他异常大对象（比如开发误建的LOB字段），否则几天后还会复发。
