最近一兩個月，一直有場景化運維、場景化大資料分析的聲音圍繞在耳畔，以Gdevops全球敏捷運維峰會杭州站上新炬網路執行副總裁程永新的“一切沒有場景驅動的運維平臺建設都是假大空！”最為振聾發聵。我們一直在談技術，談原理，談核心，總以為“懂了”這些的人，就勢必能廣闊天地大有所為。

技術固然重要，但偏離了業務/應用場景的技術，無法呈現業務價值的技術就非常不重要。

技術也應該是場景驅動的，對於運維技術人員來說，離開場景學習的所謂高深技術，只是浪費時間。所以新同事進入一個新團隊後，能使技術更好發揮作用的環境、流程的考核會佔據了另外的三分之二。

今天來談談Oracle壞塊問題。壞塊問題，相信做過兩三年Oracle維護、支援的DBA都會遇到過，即使從來沒遇到過的，看過Oracle 官方文件的甚至是會度娘或者谷哥的，應該也知道基本的處理手段。

這是我內部分享的一個簡單思維導圖，如果有遺漏，歡迎在後面評論補充。

面試的時候通常是這麼問的：你瞭解Oracle壞塊麼？壞塊為什麼會產生？描述一下你處理過的壞塊案例細節？如果你負責的好幾個資料庫都突然發生了壞塊，你會怎麼做？

通常，前面幾個問題的回答都不會太差。但是最後一個問題的回答，鮮有能出眾的。原因在於面太窄，思維太窄。如果這個時候你還要一個個庫的去看alert日誌，那麼顯然就走錯了方向。

現實情況就是，我們的資料庫可能是五六十套，或者上百套，你一套套庫的去看這些日誌裡的報錯的塊，再根據塊找到物件，確定是表還是索引，再去用壞塊的修復手段去修復…….那麼，所有人都會被你害了。

我們經歷過，花了兩天的時間，都沒修復完一個庫中幾萬個壞塊的情況，在其他大牛還在哼哧哼哧做恢復的時候，我向領導提議啟用了新的方案，在大老闆沒有完全失去耐性的情況下恢復了業務。

真正正確的做法是，如果確定壞塊數量為數眾多，趕緊停業務，切災備，後面再補資料。災備是幹什麼吃的，養庫千日，用庫一時，就在這個時候了！

非常可惜的是，大多數來面試的DBA會非常糾結於用block recover，還是用dbms_repair，還是用BBED，還是……

那麼，什麼時候往上申報，要切災備？

且不談許多公司的災備形同虛設，關鍵時候不敢切的事情。就算這些災備都是實實在在可用的，恐怕也不是說切立即就能切的，切災備涉及到應用、網路、主機、儲存等多方面的調整。

那麼多久應該切呢？一般的企業從故障處理開始，預估2小時之內不能讓業務恢復正常執行的，應該申報切災備。當然，如果是金融行業，特別是證券基金行業，1分鐘之內故障還沒恢復，就要知會證監會，半個小時沒有恢復就會受到同行業通報，所以要切就應該在這個時間之內申報。

問題又回到了原點。你得先有規劃，作為企業的重要系統，你得先建設災備環境，而且是有效的災備，並且應該事先有一個災備切換預案。

作為DBA來說，動作敏捷的檢查資料庫的情況，並及時彙報非常重要。其實這裡，又想說自動運維平臺了。通過簡單的按鈕點點，就能快速知道告警日誌裡的壞塊涉及什麼物件，是不是就好很多呢？

繼續往回看，面試的問題是什麼？是多個數據庫同時發現大量壞塊。

作為一個經驗豐富的運維管理人員，第一反應應該是，為什麼會同時發生呢？顯然是由於外因導致的。因此做好容災切換，業務恢復使用的第一時間，應該去看看這些資料庫共同的基礎是不是同樣的儲存、同樣的儲存管理軟體、卷管理軟體。

依我的經驗，大部分多個庫同時出現壞塊，都壞在儲存管理軟體身上。

有一次是Storage Foundation做卷複製的時候出現了軟體bug，IBM、Oracle、symentec等眾多廠家在“問題作戰室”裡整整呆了一個月，各家公司二線、三線出具各種證據自己沒問題，最後最後才找到蛛絲馬跡，揪出來。

還有一次稍微容易些，儲存軟體狀態恢復後壞塊沒有恢復，一個個系統通過fsck命令來進行的修復。你說，這是什麼型別的壞塊呢？

作為有經驗的DBA，要解決問題，但不要急著去敲命令，站在更高點的位置來看待問題，可能會事半功倍。

很不幸的前兩天，某個朋友公司核心資料庫“莫名奇妙”地遇到中止了。原因不方便說，但是據說等故障恢復完之後，朋友已經抽了好幾包煙了。

我們先來看看，是由於LGWR終止了資料庫（注：做了一些脫敏處理）。

但是，重啟資料庫卻發現數據庫啟動不了，發現眾多資料檔案發生了壞塊，資料庫根本不能open：

同時伴隨著類似的內部錯誤：

怎麼破？通過當天的資料庫備份結合歸檔進行恢復，遠遠比去修復壞塊要快。

解決問題時，一定是用最優先能處理好業務的技術，而不是最有技術含量的技術。

這個case裡，沒有容災環境，但幸虧有備份，不然……

文/楊志洪

原文出處——DBApius社群微信公眾號