今早运维组的同事反映有个系统功能很多地方都报错，怀疑是不是数据库有什么问题。于是登录数据库检查，通过crsctl status res -t检查，发现所有集群资源都是OK的，没有哪个资源挂掉了。于是到bdump目录下去检查alter日志文件，发现出现大量的异常日志：ORA-1653: unable to extend table SYS.AUD$。糟糕，SYSTEM估计已经满了。通过语句检查表空间使用率，发现SYSTEM表空间的数据文件已经自增长到了30G，而其中AUD$表就占用了29G，并且无法再进行自增长了。解决办法有两个：1、添加数据文件 2、将AUD$表迁移到其他表空间上。
经过短暂的考虑，由于目前应用已经异常，并且该系统用户使用较为频繁，现在客户要求最快的速度恢复业务正常，并且晚上正好安排有计划性停机检修的安排。因此，决定暂时先添加数据文件，让其先快速恢复过来。于是果断添加了10G的数据文件给SYSTEM表空间。业务应用很快恢复正常，接下来今晚还要做几个方面的工作：1、清理或迁移AUD$表的内容 2、客户打算把审计日志输出到本地的XML文件。那就要修改audit_trail参数的内容，并且重启数据库服务了。
PS：不知道该数据库是什么时候开启的审计，并且开启审计以后运维工作需要注意的事项也没有告知客户的管理员，导致出现了这样的问题。所以，对于数据库来讲，专职DBA的重要性是显而易见的，太多人经手的数据库，很容易出现各种“断片”。