《遇到大規(guī)模Oracle壞塊應(yīng)該如何處理?》要點(diǎn):
本文介紹了遇到大規(guī)模Oracle壞塊應(yīng)該如何處理?,希望對(duì)您有用。如果有疑問(wèn),可以聯(lián)系我們。
最近一兩個(gè)月,一直有場(chǎng)景化運(yùn)維、場(chǎng)景化大數(shù)據(jù)分析的聲音圍繞在耳畔,以Gdevops全球敏捷運(yùn)維峰會(huì)杭州站上新炬網(wǎng)絡(luò)執(zhí)行副總裁程永新的“一切沒(méi)有場(chǎng)景驅(qū)動(dòng)的運(yùn)維平臺(tái)建設(shè)都是假大空!”最為振聾發(fā)聵.我們一直在談技術(shù),談原理,談內(nèi)核,總以為“懂了”這些的人,就勢(shì)必能廣闊天地大有所為.
技術(shù)固然重要,但偏離了業(yè)務(wù)/應(yīng)用場(chǎng)景的技術(shù),無(wú)法呈現(xiàn)業(yè)務(wù)價(jià)值的技術(shù)就非常不重要.
技術(shù)也應(yīng)該是場(chǎng)景驅(qū)動(dòng)的,對(duì)于運(yùn)維技術(shù)人員來(lái)說(shuō),離開(kāi)場(chǎng)景學(xué)習(xí)的所謂高深技術(shù),只是浪費(fèi)時(shí)間.所以新同事進(jìn)入一個(gè)新團(tuán)隊(duì)后,能使技術(shù)更好發(fā)揮作用的環(huán)境、流程的考核會(huì)占據(jù)了另外的三分之二.
今天來(lái)談?wù)凮racle壞塊問(wèn)題.壞塊問(wèn)題,相信做過(guò)兩三年Oracle維護(hù)、支持的DBA都會(huì)遇到過(guò),即使從來(lái)沒(méi)遇到過(guò)的,看過(guò)Oracle 官方文檔的甚至是會(huì)度娘或者谷哥的,應(yīng)該也知道基本的處理手段.
這是我內(nèi)部分享的一個(gè)簡(jiǎn)單思維導(dǎo)圖,如果有遺漏,歡迎在后面評(píng)論補(bǔ)充.
面試的時(shí)候通常是這么問(wèn)的:你了解Oracle壞塊么?壞塊為什么會(huì)產(chǎn)生?描述一下你處理過(guò)的壞塊案例細(xì)節(jié)?如果你負(fù)責(zé)的好幾個(gè)數(shù)據(jù)庫(kù)都突然發(fā)生了壞塊,你會(huì)怎么做?
通常,前面幾個(gè)問(wèn)題的回答都不會(huì)太差.但是最后一個(gè)問(wèn)題的回答,鮮有能出眾的.原因在于面太窄,思維太窄.如果這個(gè)時(shí)候你還要一個(gè)個(gè)庫(kù)的去看alert日志,那么顯然就走錯(cuò)了方向.
現(xiàn)實(shí)情況就是,我們的數(shù)據(jù)庫(kù)可能是五六十套,或者上百套,你一套套庫(kù)的去看這些日志里的報(bào)錯(cuò)的塊,再根據(jù)塊找到對(duì)象,確定是表還是索引,再去用壞塊的修復(fù)手段去修復(fù)…….那么,所有人都會(huì)被你害了.
我們經(jīng)歷過(guò),花了兩天的時(shí)間,都沒(méi)修復(fù)完一個(gè)庫(kù)中幾萬(wàn)個(gè)壞塊的情況,在其他大牛還在哼哧哼哧做恢復(fù)的時(shí)候,我向領(lǐng)導(dǎo)提議啟用了新的方案,在大老板沒(méi)有完全失去耐性的情況下恢復(fù)了業(yè)務(wù).
真正正確的做法是,如果確定壞塊數(shù)量為數(shù)眾多,趕緊停業(yè)務(wù),切災(zāi)備,后面再補(bǔ)數(shù)據(jù).災(zāi)備是干什么吃的,養(yǎng)庫(kù)千日,用庫(kù)一時(shí),就在這個(gè)時(shí)候了!
非常可惜的是,大多數(shù)來(lái)面試的DBA會(huì)非常糾結(jié)于用block recover,還是用dbms_repair,還是用BBED,還是……
那么,什么時(shí)候往上申報(bào),要切災(zāi)備?
且不談許多公司的災(zāi)備形同虛設(shè),關(guān)鍵時(shí)候不敢切的事情.就算這些災(zāi)備都是實(shí)實(shí)在在可用的,恐怕也不是說(shuō)切立即就能切的,切災(zāi)備涉及到應(yīng)用、網(wǎng)絡(luò)、主機(jī)、存儲(chǔ)等多方面的調(diào)整.
那么多久應(yīng)該切呢?一般的企業(yè)從故障處理開(kāi)始,預(yù)估2小時(shí)之內(nèi)不能讓業(yè)務(wù)恢復(fù)正常運(yùn)行的,應(yīng)該申報(bào)切災(zāi)備.當(dāng)然,如果是金融行業(yè),特別是證券基金行業(yè),1分鐘之內(nèi)故障還沒(méi)恢復(fù),就要知會(huì)證監(jiān)會(huì),半個(gè)小時(shí)沒(méi)有恢復(fù)就會(huì)受到同行業(yè)通報(bào),所以要切就應(yīng)該在這個(gè)時(shí)間之內(nèi)申報(bào).
問(wèn)題又回到了原點(diǎn).你得先有規(guī)劃,作為企業(yè)的重要系統(tǒng),你得先建設(shè)災(zāi)備環(huán)境,而且是有效的災(zāi)備,并且應(yīng)該事先有一個(gè)災(zāi)備切換預(yù)案.
作為DBA來(lái)說(shuō),動(dòng)作敏捷的檢查數(shù)據(jù)庫(kù)的情況,并及時(shí)匯報(bào)非常重要.其實(shí)這里,又想說(shuō)自動(dòng)運(yùn)維平臺(tái)了.通過(guò)簡(jiǎn)單的按鈕點(diǎn)點(diǎn),就能快速知道告警日志里的壞塊涉及什么對(duì)象,是不是就好很多呢?
繼續(xù)往回看,面試的問(wèn)題是什么?是多個(gè)數(shù)據(jù)庫(kù)同時(shí)發(fā)現(xiàn)大量壞塊.
作為一個(gè)經(jīng)驗(yàn)豐富的運(yùn)維管理人員,第一反應(yīng)應(yīng)該是,為什么會(huì)同時(shí)發(fā)生呢?顯然是由于外因?qū)е碌?因此做好容災(zāi)切換,業(yè)務(wù)恢復(fù)使用的第一時(shí)間,應(yīng)該去看看這些數(shù)據(jù)庫(kù)共同的基礎(chǔ)是不是同樣的存儲(chǔ)、同樣的存儲(chǔ)管理軟件、卷管理軟件.
依我的經(jīng)驗(yàn),大部分多個(gè)庫(kù)同時(shí)出現(xiàn)壞塊,都?jí)脑诖鎯?chǔ)管理軟件身上.
有一次是Storage Foundation做卷復(fù)制的時(shí)候出現(xiàn)了軟件bug,IBM、Oracle、symentec等眾多廠家在“問(wèn)題作戰(zhàn)室”里整整呆了一個(gè)月,各家公司二線、三線出具各種證據(jù)自己沒(méi)問(wèn)題,最后最后才找到蛛絲馬跡,揪出來(lái).
還有一次稍微容易些,存儲(chǔ)軟件狀態(tài)恢復(fù)后壞塊沒(méi)有恢復(fù),一個(gè)個(gè)系統(tǒng)通過(guò)fsck命令來(lái)進(jìn)行的修復(fù).你說(shuō),這是什么類型的壞塊呢?
作為有經(jīng)驗(yàn)的DBA,要解決問(wèn)題,但不要急著去敲命令,站在更高點(diǎn)的位置來(lái)看待問(wèn)題,可能會(huì)事半功倍.
很不幸的前兩天,某個(gè)朋友公司核心數(shù)據(jù)庫(kù)“莫名奇妙”地遇到中止了.原因不方便說(shuō),但是據(jù)說(shuō)等故障恢復(fù)完之后,朋友已經(jīng)抽了好幾包煙了.
我們先來(lái)看看,是由于LGWR終止了數(shù)據(jù)庫(kù)(注:做了一些脫敏處理).
但是,重啟數(shù)據(jù)庫(kù)卻發(fā)現(xiàn)數(shù)據(jù)庫(kù)啟動(dòng)不了,發(fā)現(xiàn)眾多數(shù)據(jù)文件發(fā)生了壞塊,數(shù)據(jù)庫(kù)根本不能open:
同時(shí)伴隨著類似的內(nèi)部錯(cuò)誤:
怎么破?通過(guò)當(dāng)天的數(shù)據(jù)庫(kù)備份結(jié)合歸檔進(jìn)行恢復(fù),遠(yuǎn)遠(yuǎn)比去修復(fù)壞塊要快.
解決問(wèn)題時(shí),一定是用最優(yōu)先能處理好業(yè)務(wù)的技術(shù),而不是最有技術(shù)含量的技術(shù).
這個(gè)case里,沒(méi)有容災(zāi)環(huán)境,但幸虧有備份,不然……
文/楊志洪
原文出處——DBApius社群微信公眾號(hào)
轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址:
http://www.snjht.com/jiaocheng/4518.html