一次数据块恢复操作
今天中午遇見一個生產(chǎn)數(shù)據(jù)庫宕機(jī)，需要處理，下面是處理的過程記錄
1、Startup到mount是沒有問題的，但是Open時報
ORA-03113: end-of-file on communication channel?
其實這個錯誤經(jīng)常會遇到的, 導(dǎo)致這個錯誤的原因有很多種(大約):
·???????????????????? ?系統(tǒng)的核心參數(shù)設(shè)置不恰當(dāng)
·???????????????????? ?oracle環(huán)境變量和權(quán)限
·???????????????????? ?SQL,PL/SQL引起的錯誤
·???????????????????? ?磁盤空間滿
·???????????????????? ?防火墻問題
·???????????????????? ?其它因素
?2、 由于是一個正常運(yùn)行的生產(chǎn)庫，突發(fā)這個問題，所以，排除了環(huán)境變量什么的問題，查看磁盤空間，也沒有問題，剩余空間很大，那么，問題就是加載數(shù)據(jù)文件時出現(xiàn)的，仔細(xì)查看Alert.log,
?發(fā)現(xiàn)，數(shù)據(jù)文件6出現(xiàn)block recovery的報警
?Doing block recovery for file 6 block 150469
3、既然是數(shù)據(jù)文件損壞，使用DBV工具對數(shù)據(jù)塊進(jìn)行檢查。
通過幾分鐘等待，顯示壞塊為150469，如下圖（另有Blog文章專門針對DBV使用方法的介紹）
4、確認(rèn)數(shù)據(jù)文件問題以后，打算將該 restore datafile，但是在確認(rèn)restore datafile命令的時候，想起blockrecover 工具，由于只有一個壞塊，所以決定嘗試使用blockrecover去恢復(fù)（第一次在生產(chǎn)環(huán)境使用這個命令哦，之前全部是測試環(huán)境）。
????? 由于沒有實際在生產(chǎn)環(huán)境中使用該命令，所以，立即google前人經(jīng)驗，經(jīng)過總結(jié)多個高手的經(jīng)驗，開始了壞塊修復(fù)，（另有Blog文章專門針對Blockrecover使用方法的介紹）
?由于公司使用帶庫，所以rman腳本如下進(jìn)行恢復(fù)，
?
?
?觀察alert.log發(fā)現(xiàn)如下日志，在Starting block media recovery之后應(yīng)用了
大約10分鐘后，recover完成，數(shù)據(jù)塊正常Open
? 5、修復(fù)之后再次用DBV數(shù)據(jù)文件，確認(rèn)已經(jīng)修復(fù)成功（其實多余，呵呵，為什么呢？因為數(shù)據(jù)庫已經(jīng)open成功了啊！數(shù)據(jù)文件當(dāng)然已經(jīng)是沒有問題的，不然….你懂的）
???? 總結(jié)，有些知識不常用，平時記憶不清晰，不牢固，所以使用的時候還需要到google去查詢具體命令，防止犯低級的命令錯誤。所以還要加強(qiáng)記憶。
? ??? 同時由于很多知識，尤其是恢復(fù)類的，在實戰(zhàn)中真的很少用到，使用時，還是很有壓力的，畢竟生產(chǎn)庫的宕機(jī)，恢復(fù)的時效性和恢復(fù)的正確性是不容疏忽的，當(dāng)recover完成，alter database open成功的那一刻，還是有點(diǎn)小興奮的，畢竟，這是一件好事，證明自己的工作有效果的嗎！收獲還是高興的。
???? 之后，我要把DBV和blockrecover的知識整理下，寫上來。
轉(zhuǎn)載于:https://blog.51cto.com/hsbxxl/749457
總結(jié)
- 上一篇： windows系统登陆就注销如何解决,系
- 下一篇： 生命里没有“浪费”