今天一早來,就發現小瑞的Oracle DB 出現問題,難道是我叫網管把乖乖拿出來的報應。先檢查一下,到底是什麼病症,再準備好必要的急救手術。

嚇一跳的青蛙
引用至 懶人小站 站長 青蛙嚇一跳 作品

進機房後,看到奄奄一息的DB ,來不及跟它打招呼,就往生了。沒有辦法,只好由外層進行檢查,查看是什麼問題。經過多個檢查程序後,發現主要問題在,開機的那個 OS partition 有狀況,出現ext3-fs error 的問題。

目前除了這個問題之外,另外DB 存放datafile 的那個 partition 及Arch log 的partition 看起來是正常的。

所以要解決這個問題,有兩個思考方向:
1. 把OS 的那個partition 重裝
2. 由Dataguard 接手,由standby db 轉為 primary db

如果第1個情況所花的時間,超過2小時,我就會考慮使用第2個做法。不過之前網管,沒有每天去檢查dataguard 的log apply 是否正常,結果在上一次,DB 出問題時,有某一個log 沒有被正常的apply ,造成之後的log 沒有辦法,接續著apply ,所以沒有成功的接手,成為primary db ,那是一次失敗經驗。之後在網管的日常工作中,除了檢查RMAN 的備份是否正常外,另加入一項,檢查dataguard 的log apply 作業,是否正常。

在這樣的要求下,這一次dataguard 接手,算是準備完全,隨時可以接手。就看OS 重新倒回來的時間。

因為在DB 上的架構是把純OS 另切一個partition ,data 及 program 另外放一個partition ,所以只要處理那個壞的 partition 即可,重新安裝,應該會超過2小時,User 等待時間太長,不是很理想。而之前有針對這個partition 進行過dd 備份,也就是windows 上常用的 ghost 技倆。

由NAS 上直接把那個 images file ,直接透過 dd 指令,倒回底層的LVM 的LV 上,指令參考如下:


指令在NAS 那台下
dd bs=64k if=/backup/dbos.img | ssh 192.168.xx.xx "( dd bs=64k of=/dev/Volgroup00/dbos_lv )"

由server lan 傳檔,大約10分鐘左右,搞定後,果然重啟DB 那台虛機,即正常開機成功。開完機後,再針對DB 的datafile 那個 partition 進行 e2fsck 檢查一下及修復一下disk error ,整個過程大約30分鐘,DB Server 就回魂了。

這一次處理問題的心情是,很輕鬆,一點都不擔心。備份,真的很重要,雖然平常用不到,但發生狀況時,因為這個備份,可以減少User Data 的損失,及IT 人員回復的時間。

所以MIS同志們,請乖乖的定時做備份哦^_^

日期:2010/03/30 | 留言:0 個 | 作者:Rico | 瀏覽:
分類:MIS鳥日記
標籤:, , , , , , ,
  1. 目前還沒有留言!
  1. 目前沒有引用。

*

Copyright -0001 紐菲斯的部落格