system表空間不足的問題分析

很多事情見多了也就有了麻木的感覺，報警簡訊就是如此，每天總能收到不少的報警簡訊，可能很多時候就掃一眼，如果沒有嚴重的問題自己是不會情願開啟電腦處理的。
對於此，有些朋友說是不是閥值太低了，調高一些報警就少了，如果那樣做，監控的意義也就大大不同了。很多時候硬體錯誤或者系統錯誤不是突然出現問題，而是在一些異常的情況下執行，時間長了，難免出錯，打個比方，如果兩個配置一模一樣的系統，一個核心引數有問題，資源使用有異常，總是CPU滿負荷空跑，產生了大量的IO浪費，而另外一臺，就是真正的空閒，負載不高，各項指標正常，那麼在時間的檢驗下，負載高的伺服器出錯的機率就要大的多，可能CPU壞掉，磁碟壞掉。這種情況其實就不是偶然而是必然了。
對於報警簡訊，我的理念就是既然設定了一個相對統一的閥值，那麼對於OLTP和OLAP的系統都應該基本遵守這個規則，既然它報出了那麼多的錯誤，那肯定後臺在進行什麼樣的操作，有什麼改進的地方，或者潛在的問題，目前根據我的實踐，絕大多數的報警資訊中，如果抓住某一條報警資訊去分析，都能或多或少分析出點東西來，有些是資源使用不合理，有些是sql語句的問題，有些是歷史遺留問題，有些甚至正在醞釀成為大問題。
分析了，解決了，報警簡訊就會少一些，這樣工作量也會大大減少。如果單純為了提高閥值而減少報警，那也是自欺欺人。
我可以舉個例子來佐證。
比如一條常規的報警簡訊，提示表空間不足。
收到的報警簡訊內容如下：
監控專案: showtsps：-->TS_NAME:SYSTEM :10% Free 
------------------------------------ 
報警時間:2015.09.21-04:32:49
SYSAUX             1,040         78         962 
SYSTEM           29,530       26      29,504
TEMP                 29            28           1
UNDOTBS1       3,315      3,241          74
USERS              5,963        285       5,678
對於這類問題，一般的思路就是擴充表空間，當前表空間已經試29G左右了。再擴充，這個資料檔案還能再擴幾個G。
但是反過來想，系統表空間怎麼會消耗這麼多的空間呢，就算一個庫再大，資料字典的資訊也多不了太多，而且還有SYSAUX的輔助，不至於那麼緊張。
空間都消耗在哪兒了呢，第一個反應就是可能其他的使用者建立了一些臨時表，由於沒有遵守規則導致表資料都放在了SYSTEM表空間裡。
但是檢視之後，欣慰的是不是這個問題導致的。
那麼空間的消耗從哪兒來呢，一個最直接的思想就是審計日誌。
在11g的庫中，審計的級別預設是DB會產生不少的審計日誌資訊，那麼這些資訊主要存放在哪兒呢，就是au$裡面。
這是一個基表，很多審計相關的檢視，資料字典都會參考這個基表。
SEGMENT_TYPE       SIZE_MB SEGMENT_NAME
--------------- ---------- ------------------------------
TABLE                28785 AUD$