存儲Cache丟失導(dǎo)致數(shù)據(jù)庫無法open的案例
當(dāng)存儲Cache由于丟失時，我們應(yīng)該如何處理，讓數(shù)據(jù)庫重新能夠open起來呢？讓我們聽聽，專家分享的這篇案例。
發(fā)現(xiàn)問題
最近某客戶的一套核心數(shù)據(jù)庫由于存儲問題導(dǎo)致清掉Cache之后無法啟動。首先我們來看看數(shù)據(jù)庫在啟動的時候報什么錯誤：
錯誤并不復(fù)雜?？梢钥吹絆racle這里已經(jīng)無法正常寫Redo logfile了。
解決思路
由于這套數(shù)據(jù)庫是非歸檔，只有邏輯備份，因此即使恢復(fù)成功也面臨數(shù)據(jù)丟失的可能性。
首先我在嘗試進(jìn)行恢復(fù)時，發(fā)現(xiàn)居然無法mount數(shù)據(jù)庫，在mount過程中實例被直接終止了，感覺非常奇怪。也沒有報非常明顯的錯誤。mount過程出錯，那么無疑是controlfile存在異常；由于沒有controlfile備份，因此這里先手工重建控制文件，如下是腳本:
重建完畢后。其實這里我首先嘗試了進(jìn)行noresetlogs創(chuàng)建，但是發(fā)現(xiàn)報錯：
很明顯，Redo logfile有問題。
看來還是只能Resetlogs方式創(chuàng)建。創(chuàng)建完畢之后，嘗試進(jìn)行了recover database using backup controlfile until cancel恢復(fù)操作；然后通過隱含參數(shù)強制open發(fā)現(xiàn)還是有如下錯誤：
這是非常經(jīng)典的錯誤了，由于這是scn的問題，而且數(shù)據(jù)庫版本為11.2.0.3.0，未安裝任何psu。因此這里是可以直接推進(jìn)scn的。
直接通過10015 event 來推進(jìn)數(shù)據(jù)庫的scn；另外由于是異常關(guān)機，那么這里Undo 必然也無法進(jìn)行正?；謴?fù)；因此同時設(shè)置 undo_management 參數(shù)為manual，并同時設(shè)置10015 event：
- alter session set events ‘10015 trace name adjust_scn level 2’;
順利打開了數(shù)據(jù)庫。打開數(shù)據(jù)庫之后立刻重建數(shù)據(jù)庫Undo和temp，如下：
再次重啟數(shù)據(jù)庫之后，發(fā)現(xiàn)alert log仍然有一些錯誤。如下所示：
實際上當(dāng)時在進(jìn)行恢復(fù)時，我手工處理掉了obj＃ 290。但是進(jìn)一步檢查發(fā)現(xiàn)obj$,col_usage$ ,i_obj4# 都存在問題。而且不一致的記錄還比較多：
最開始我還嘗試通過bbed修復(fù)了2個Block；***發(fā)現(xiàn)依然難以處理這個ora-08102錯誤；后續(xù)通過上述sql比較發(fā)現(xiàn)居然有如此多的記錄不一致。修改起來太過麻煩了。
這里其實本來想嘗試通過重建obj$,i_obj4$,col_usage$ 來解決的。但是擔(dān)心有較大的風(fēng)險,因此這里建議可以進(jìn)行了數(shù)據(jù)庫重建。由于obj$這里有問題，expdp操作都報錯，無法執(zhí)行任何ddl操作。因此***通過exp拆分腳本來進(jìn)行重建處理。整個數(shù)據(jù)庫恢復(fù)+重建過程將近20小時左右(2tb左右的庫).
由于客戶存儲環(huán)境io較差，因此導(dǎo)致整個重建過程比較復(fù)雜，比較耗時。我們在開玩笑講到：如果可能的數(shù)據(jù)庫運行在我們的Zdata環(huán)境上，那么數(shù)據(jù)庫重建過程在2小時內(nèi)即可完成，而且也不會出現(xiàn)類似故障。因此Zdata的io操作上直接落盤或者寫到Pcie上，不存在數(shù)據(jù)丟失的風(fēng)險。
補充說明
1) 由于數(shù)據(jù)庫很多事務(wù)無法正?；謴?fù)，導(dǎo)致SMON在不斷嘗試進(jìn)行事務(wù)恢復(fù)時報錯，達(dá)到一定次數(shù)之后會crash實例，進(jìn)而影響數(shù)據(jù)庫的重建工作。可通過設(shè)置_smon_internal_errlimit 參數(shù)來避免該問題。
2) 為了加快exp和imp速度，這里我們利用了管道技術(shù)，腳本如下：
