今天一早來，就發現小瑞的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同志們，請乖乖的定時做備份哦^_^
分類：MIS鳥日記
標籤：apply log, Dataguard, dd, LVM, primary db, RMAN, standby db, 乖乖
