一次歸檔報錯的處理和分析

昨天在睡覺前接到了一條報警簡訊，本來已經疲倦的身輕如燕，但是看到報警，還是警覺了起來

ZABBIX-監控系統:
------------------------------------
報警內容: DG_issue
------------------------------------
報警級別: PROBLEM
------------------------------------
監控專案: dg_issue：2015-12-27 00:35:17.0Log Transport ServicesErrorARC0: Encountered disk I/O error 195022015-12-27 00:35:17.0Log Transport ServicesErrorARC0: I/O error 19502 archiving log 1 to '/U01/app/oracle/oradata/test/archive/TEST/archivelog/2015_12_27/o1_mf_1_71969_c7xjg564_.arc'
------------------------------------
報警時間:2015.12.27-00:35:22

登入到主庫，看到磁碟空間確實已經滿了。使用普通的DB使用者已經登入不了了。幾個和磁碟空間相關的分割槽情況如下。當時/dev/sdb還剩下不到2G。
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda8             243G  103G  129G  45% /home
/dev/sdb              1.7T  1.6T   29G  99% /U01
對於這個問題，自己為了火速進行處理，就從/U01下面開始找檔案進行清理，首要就是找歸檔檔案，但是失望的是發現歸檔檔案現在確實也不多了。而且目前的歸檔刪除策略也是半個小時刪除一次。截止到問題發生的時候，歸檔檔案只有4個，而且也是半個小時內生成的，就算刪除了也騰不出多少空間，更關鍵的是還需要到備庫去檢視是否歸檔已經接受。所以簡單確認之後從主庫刪除了已經被備庫應用的歸檔，省下來1個G多一點的空間，問題暫時解決了，就開始從其他目錄檢視是否還有更多的空間清理，但是發現除了一些歷史的日誌，其實可清理的空間也就不到1G.
所以這個時候問題很可能再次發生，需要馬上進行處理。
從目前的情況來看/U01下的空間確實屈指可數，改進空間已經不大了。那麼還有一個分割槽就是/home大概還有幾百個G還能勉強應付一下。
這個時候一種方法就是把歸檔路徑直接切換到/home分割槽下，但是這種變更很快會導致dg broker報警，為了減少給監控同學更多的解釋和對系統本身的影響，我決定下臨時把歸檔目錄切過去。
比如今天是12月27日，就在/home/下生成一個軟連結,比如我現在給自己幾天的buffer時間，這部分的100多G的空間就先在這個目錄下重新整理，不會有太大的抖動。
[oracle@tlbb3dbidb arch]$ ll
lrwxrwxrwx 1 oracle oinstall 71 Dec 27 01:17 2015_12_27 -> /U01/app/oracle/oradata/test/archive/TEST/archivelog/2015_12_27
lrwxrwxrwx 1 oracle oinstall 71 Dec 27 01:21 2015_12_28 -> /U01/app/oracle/oradata/test/archive/TEST/archivelog/2015_12_28
lrwxrwxrwx 1 oracle oinstall 71 Dec 27 01:22 2015_12_29 -> /U01/app/oracle/oradata/test/archive/TEST/archivelog/2015_12_29
lrwxrwxrwx 1 oracle oinstall 71 Dec 27 01:22 2015_12_30 -> /U01/app/oracle/oradata/test/archive/TEST/archivelog/2015_12_30
當然這個問題為什麼沒有早點發現，其實很早就發現了，但是對於這個統計庫的空間問題，閥值設定為90~95%，但是老是報警，而且又沒有更多的空間就擱置下來了。所以先這樣處理，自己也好協調跟進。
當然回過頭來，這麼多空間都消耗在哪裡了。可以從下面的圖形看出，其實最近的歸檔切換頻率在凌晨會有一個小高峰，應該是批量的資料處理。之後基本趨於穩定。

所以對於這個問題的更深一層的分析，就是如果空間的消耗在逐漸增大，那麼這個空間的消耗瓶頸在哪裡。
其實想得到這個結果，也是分分鐘就會有結果。直接從dba_segments裡面查詢即可。可以看到下面的幾個表的空間佔用極高。
segment_name               segment_type                             bytes_MB
LOGIN_LOG                      TABLE PARTITION                      103331
M_START_LOG                    TABLE PARTITION                      117842
MOL_TIME                       INDEX PARTITION                      120922
M_ONLINE_LOG                   TABLE PARTITION                      809661
這個M_ONLINE_LOG竟然佔用了近800多個G，作為一個分割槽表而言資料量也著實驚人。
那麼這部分資料是不是歷史資料太多了呢，發現資料量也是在逐漸遞增，而且都是近半年的資料。沒有之前的歷史資料了。
分割槽從4月份開始的資料增長情況如下：

看來最近的資料增長情況還在不斷遞增，所以這個問題還是有很多的確認之處，是否需要這麼多的資料，如果確實需要，需要進一步考慮掛載新的分割槽，如果只是需要部分的資料，那麼就需要考慮一個持久的資料清理方案。夜深了，看看手機，應很晚了。工作是幹不完的，睡覺睡覺。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-1965457/，如需轉載，請註明出處，否則將追究法律責任。