很多事情見多了也就有了麻木的感覺，報警簡訊就是如此，每天總能收到不少的報警簡訊，可能很多時候就掃一眼，如果沒有嚴重的問題自己是不會情願開啟電腦處理的。
對於此，有些朋友說是不是閥值太低了，調高一些報警就少了，如果那樣做，監控的意義也就大大不同了。很多時候硬體錯誤或者系統錯誤不是突然出現問題，而是在一些異常的情況下執行，時間長了，難免出錯，打個比方，如果兩個配置一模一樣的系統，一個核心引數有問題，資源使用有異常，總是CPU滿負荷空跑，產生了大量的IO浪費，而另外一臺，就是真正的空閒，負載不高，各項指標正常，那麼在時間的檢驗下，負載高的伺服器出錯的機率就要大的多，可能CPU壞掉，磁碟壞掉。這種情況其實就不是偶然而是必然了。
對於報警簡訊，我的理念就是既然設定了一個相對統一的閥值，那麼對於OLTP和OLAP的系統都應該基本遵守這個規則，既然它報出了那麼多的錯誤，那肯定後臺在進行什麼樣的操作，有什麼改進的地方，或者潛在的問題，目前根據我的實踐，絕大多數的報警資訊中，如果抓住某一條報警資訊去分析，都能或多或少分析出點東西來，有些是資源使用不合理，有些是sql語句的問題，有些是歷史遺留問題，有些甚至正在醞釀成為大問題。
分析了，解決了，報警簡訊就會少一些，這樣工作量也會大大減少。如果單純為了提高閥值而減少報警，那也是自欺欺人。
我可以舉個例子來佐證。
比如一條常規的報警簡訊，提示表空間不足。
收到的報警簡訊內容如下：
監控專案: showtsps：-->TS_NAME:SYSTEM :10% Free
------------------------------------
報警時間:2015.09.21-04:32:49

這個資訊充分說明SYSTEM表空間不足了，需要擴充。
而檢視錶空間的使用情況，發現系統表空間確實只剩餘26M了，空間使用算是非常緊張了。
Tablespace Total MB Free MB Used MB
-------------------- --- - - ---- ------------ ---------- ------

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$

結果一看還確實，這個表佔用了絕大多數的系統表空間。
那麼處理方法似乎就很簡單了。直接清理掉這個基表即可。
思路很簡單，但是這是線上應用，我還是希望自己能夠佐證一些，如果為了調優結果造成了系統故障就是得不償失了。
首先檢視清理aud$這個基表是否有一些bug,結果還真查到一個。Deadlock Problem On Sys.Aud$ Table. (文件 ID 1199416.1)，仔細檢視之後發現這個問題的版本要早一些，
問題已經在新的版本修復，所以這個問題目前不大可能出現在我目前的環境中，那麼接著檢視是否有一些官方的說法呢。
How to Truncate, Delete, or Purge Rows from the Audit Trail Table AUD$ (文件 ID 73408.1)

對於清理這個基表，思路還是很簡單，簡單的評估檢查之後，最關鍵的還是執行truncate table au$.
檢視了官方文件，自己也有底了，當然這部分審計資訊需要確認為不需要的。因為目前還沒有定製更多的審計級別和審計資訊。

SQL> truncate table aud$;
Table truncated.

這個時候再次檢視空間使用情況，其實system表空間使用了總共720M,剩下的空間都得到了釋放。

Tablespace Total MB Free MB Used MB
-------------------- --- - - ---- ------------ ---------- ------

SYSAUX   1,040 78 962
SYSTEM   29,530   28,811   720
TEMP       29    28 1
UNDOTBS1   3,315 3,241 74
USERS 5,963 285 5,678

這樣這個問題就基本修復了，至少在很長的一段時間裡都不會在有類似的問題。
都說前人栽樹後人乘涼，我還是不希望成為前人埋雷後人踩，畢竟這種問題攤到自己身上還是很鬱悶的。

system表空間不足的問題分析

相關文章