目录
项目场景：
问题描述
原因分析：
解决方案：
项目场景：上个周日早晨，我所负责的其中一个项目现场打电话来把我从一场美梦中叫醒。操着一种如果没大事儿肯定给你头干爆的情绪问：怎么了！
然后我同事甩给我一张图片，看微信！
数据库连不上了，你还睡！
问题描述 ORA-01653报错数据库客户端连接不上各种涉及该数据库的程序接口全部报错这是彼时彼刻项目现场的问题情况描述，待在项目现场的是个刚入职不久的新同事，没见过这个报错，着急上火很正常。但作为一个立志要做一个优秀DBA工程师的ETL工程师，私下偷偷卷了下，反应过来“SYSTEM表空间满了”。
于是和新人同事回复：
“莫慌，顶天了就是跑路.....”
原因分析：原因分析其实很简单，可以从下面几个思路去考虑：
SYSTEM表空间满了SYSTEM表空间中存储的内容是Oracle最重要的核心系统数据，一旦它出了问题，那么整个数据库都会受到影响。这块内容可以参考我的另一篇文章：浅谈Oracle存储管理（一）：存储结构 ，这篇文章中有简单提到SYSTEM表空间的相关知识。
审计数据这一条原因从本质上来说还是空间资源问题，只不过是直接从审计数据过大导致SYSTEM空间爆满这个方向去思考。Oracle如果开启了审计，审计数据是默认存储到SYSTEM表空间中。审计数据是不断增长的，如果不定期对其进行清理，必然会导致空间爆满。
解决方案：如果您此时此刻正在经历此故障，可以按照如下步骤进行操作。
第一步第一步，先救命。通过sqlplus登录故障数据库（此时客户端是肯定不能连接了，但sqlplus可以）。给SYSTEM表空间添加数据文件，这个是最快最有效的解决问题的方法。
查询出数据文件路径
select name from v$datafile;添加数据文件；数据文件名根据最后一个编号继续添加下去，且路径保持一致。
ALTER TABLESPACE SYSTEM ADD DATAFILE '/u01/app/oracle/oradata/ORCL/system03.dbf' SIZE 100M AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED添加完数据文件，ORA-01653报错消失；接口程序恢复正常，客户端正常连接。“这个是最快最有效的解决问题的方法” ，但不是最根本的解决方法。
第二步添加数据文件不是最根本的解决方法，如果不查明数据暴涨原因，还是会继续发生该问题。SYSTEM表空间是不会用来存储业务数据的。那么引起它空间使用飙升最有可能的原因是审计数据过大。
首先需要先查看数据库是否开启了审计
执行如下命令，如果VALUE显示DB或者XML，则表示开启了审计。如果显示为NONE，则表示未开启审计；那就不是审计数据导致的，需要从其他方面分析原因。
SQL> show parameter audit_trailNAME TYPEVALUE------------- ----------- -----------audit_trail string DB在确认开启审计数据后，查看审计数据大小。
SELECT ROUND(BYTES/1024/1024/1024,2) AS AUD_SIZEFROM DBA_SEGMENTSWHERE TABLESPACE_NAME = 'SYSTEM'AND SEGMENT_NAME = 'AUD$'如果发现此时的SYS.AUD$已经占用存储相对很大了，比如SYSTEM表空间总共才32G，它已经占用了10G左右，那么可以对其进行清理了。
TRUNCATE TABLE SYS.AUD$审计数据是不断生成的，保存太久的审计数据是没有意义的，所以您也可以设置JOB定期进行清除。
第三步如果通过第二步发现数据库未开启审计，或者审计数据并不大，此时就需要对SYSTEM表空间下存储的数据进行深入分析。 查看SYSTEM表空间下所有占用存储比较大的对象，再进行具体的分析。
SELECT * FROM(SELECT OWNER,SEGMENT_NAME,SEGMENT_TYPE,ROUND(BYTES/1024/1024/1024,2) AS SEG_SIZE_GBFROM DBA_SEGMENTS DSWHERE TABLESPACE_NAME = 'SYSTEM'ORDER BY BYTES DESC)WHERE ROWNUM