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/，如需轉載，請註明出處，否則將追究法律責任。