ORA-09817 trace文件目录满了

今天上午导收银监控例行报表，时间写的是2012-01-06到2012-01-12，在pl/sql运行，结果报错，
错误为ORA-29701：unable to connect to cluster manager，网上说这可能是一个关于ASM或者
是SQL内部调用的问题，问题是我把日期换成2011年的，SQL能正常跑出来，没有任何问题，也暂
时没收到运维打来的电话。查询节点2上告警日志，没有抛出错误，再查看一下今天的逻辑备份
日志，发现备份失败，日志内容如下
 
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options
ORA-39097: Data Pump job encountered unexpected error -31616
ORA-39065: unexpected master process exception in FILE
ORA-31616: unable to write to dump file "/crmdb2_bk/dump/120113.dmp"
ORA-29701: unable to connect to Cluster Manager

在日志报错里面仍然看到了ORA-29701这句话，在这里把方向转向了磁盘上面去，在节点2上面
用df -k检查了一下/crmdb2_bk的空间，发现还有很多，一般逻辑备份失败是出现在磁盘不够的
情况下，而今天磁盘还多，而且dmp文件一点都没有生成，这样的话就不应该是这个地方问题，
同时观察到/oracle这个目录已经满了，去bdump下面删除了一个4G大的trace文件，在执行上面
的SQL,仍然失败。这个时候铁勇重新pl/sql developer登陆的时候报错了
，ORA-09817:   Write   to   audit   file   failed.
他说这是审计的错误，那么将问题定位到cd /oracle/admin/jsj/adump/下面，发现这个下面有
差不多8G的ora_xxxx.aud文件，将其文件全部删除，问题得以解决。后面证实这些是我们登陆
数据库时记录的审计文件。最后将其bdump下面的trace文件全部删除，/oracle 使用率降低的37%左右

随后杨洪出来前段有人在做业务操作的时候也报出了ORA-29701，在问题解决后，那边得以正常使用
以后要多注意下磁盘空间的使用率并且定期清理一下trace文件

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10678398/viewspace-715113/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10678398/viewspace-715113/