system表空間不足的問題分析(r6筆記第66天)
很多事情見多了也就有了麻木的感覺,報警簡訊就是如此,每天總能收到不少的報警簡訊,可能很多時候就掃一眼,如果沒有嚴重的問題自己是不會情願開啟電腦處理的。 對於此,有些朋友說是不是閥值太低了,調高一些報警就少了,如果那樣做,監控的意義也就大大不同了。很多時候硬體錯誤或者系統錯誤不是突然出現問題,而是在一些異常的情況下執行,時間長了,難免出錯,打個比方,如果兩個配置一模一樣的系統,一個核心引數有問題,資源使用有異常,總是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
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
這樣這個問題就基本修復了,至少在很長的一段時間裡都不會在有類似的問題。 都說前人栽樹後人乘涼,我還是不希望成為前人埋雷後人踩,畢竟這種問題攤到自己身上還是很鬱悶的。