最近一兩個月，一直有場景化運維、場景化大數據分析的聲音圍繞在耳畔，以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裡，沒有容災環境，但幸虧有備份，不然……
