问题描述：
公司的一套12.1.0.1 ADG数据库出现问题。该ADG包含4个PDB，是2节点RAC。其中一个节点的audit目录在短时间内生成海量.aut文件，最终将该目录所在挂载点撑满，导致数据库不可用。 在2015年就有公司这么使用数据库了，是不是有些冒险。 答案是肯定的，对于运维DBA来说真是痛并快乐着。
出现问题的目录为： /u01/12.1.0.1/grid/rdbms/audit
目录中的文件名类似于：
+ASM2_ora_9936_20150504170002511158143795.aud
+ASM2_ora_9949_20150504170002684522143795.aud
+ASM2_ora_9955_20150504170002699470143795.aud
文件大小都是700bytes，打开文件后看不到任何关于审计的内容，只有一个冒号和数字2， ：2
由于该目录文件增长迅猛，10小时可达65GB，不得已采用了crontab每隔10分钟清除一次该目录中的垃圾文件。如果间隔1小时删除一次都会因为文件过多而rm失败！
$ crontab -l
0,10,20,30,40,50 * * * * cd && . ./.profile && /home/grid/scripts/admin/removetrace.sh
rm /u01/12.1.0.1/grid/rdbms/audit/*
问题分析：
审计设置：
虽然在实例级别设置了审计目录为OS方式，审计信息保存在目录/u01/12.1.0.1/oracle/admin/<SID>/adump,不会保存在SYSAUX表空间。 注意，这个OS地址并不是出问题的那个目录。
SQL*Plus: Release 12.1.0.1.0 Production on Mon May 4 16:54:44 2015
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, Oracle Label Security,
OLAP, Advanced Analytics, Oracle Database Vault and Real Application Testing options
SQL >select value from v$option where parameter=‘Unified Auditing‘;
VALUE
----------------------------------------------------------------
FALSE
SYS@jzdbc2 >show parameter audit
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest string /u01/12.1.0.1/oracle/admin/jzd
bc/adump
audit_sys_operations boolean FALSE
audit_syslog_level string
audit_trail string OS
unified_audit_sga_queue_size integer 1048576
在看看ASM实例中的状况，并没有开启audit_trail。 但是默认路径和出问题的目录一致，可以断定是由于触发了对ASM实例的审计触发了该bug。
su - grid
sqlplus / as sysdba
------------------------------------ ----------- ------------------------------
audit_file_dest string /u01/12.1.0.1/grid/rdbms/audit
audit_sys_operations boolean FALSE
audit_syslog_level string
unified_audit_sga_queue_size integer 1048576
查看过所有监控脚本，也核对过Cloud Control的监控设置，都不存在sys用户直接连接ASM实例触发审计的状况。
解决方案：
该问题发送support oracle并没有得到答复。最终期待这个bug可以通过重启主机来解决。 这个重启大法并不是迷信，也并不只适用于windows。有时候也适用于安装在HP Unix上的Oracle12c。 如果是运行在AIX上，我还真不会期待奇迹发生。但是HP，还是值得期盼一下的。
终于盼到周末检修。主机重启后，问题解决了。 /u01/12.1.0.1/grid/rdbms/audit每分钟产生一个.aut文件，不再暴增。aut文件依然没有任何信息，还是只有：2，还是只有700bytes大小，但是我不再担心磁盘空间了。 希望Oracle能尽快修复这个bug。
全文完
12c ASM audit目录增长过快的bug
原文：http://blog.itpub.net/29047826/viewspace-1659960/
