最近一兩個月，一直有場景化運維、場景化大資料分析的聲音圍繞在耳畔，以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裡，沒有容災環境，但幸虧有備份，不然……
作者介紹 楊志洪
【dbaplus社群】聯合發起人，新炬網絡首席布道師；
資料管理專家，擁有十餘年電信、銀行、保險等大型行業核心系統oracle資料庫運維支援經驗，掌握itil運維體系，擅長端到端性能優化、複雜問題處理。現主要從事資料架構、高可用及容災咨詢服務；
oracle ace、ocm、《oracle核心技術》譯者。
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-05-21</b>