問題描述：

公司的一套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//adump,不會儲存在SYSAUX表空間。注意，這個OS地址並不是出問題的那個目錄。

SQL*Plus: Release 12.1.0.1.0 Production on Mon May 4 16:54:44 2015

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

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

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

相關文章