資料通常比喻為企業的血液和生命，資料安全一直是大家非常重視的話題。

Oracle資料庫，為了防止資料丟失以及構建高可用環境給出了多種架構方式。例如，為了防止Oracle例項級別的單點故障提供了RAC技術（Real Application Clusters，真正的應用叢集），RAC以Share Everything的架構方式使多個主機例項可以共享一套儲存上的資料，從而避免了由於個別例項出現故障導致資料庫不可用；RAC技術僅僅給出了例項層面的高可用解決方案，為了防止儲存層面的單點故障，Oracle又提出了Data Guard（資料衛士）技術，無論是邏輯Data Guard還是物理Data Guard都從儲存層面解決了單點故障，同時也是災備技術的最佳選擇。基於RAC和Data Guard技術，Oracle進一步又推出了MAA架構方式，即主站點是RAC架構方式，備用站點也是RAC架構方式，主備站點之間透過Data Guard技術使用redo傳輸變化的資料，確保備站點與主站點之間達到實時或者準實時的資料一致。

除此之外，Oracle還提供了各種備份恢復工具，比如物理備份恢復工具RMAN、邏輯備份恢復工具EXP/IMP EXPDP/IMPDP。基於這些工具便可以定製一套有效的備份恢復策略，以便防止資料丟失。

以上技術手段都是確保資料不丟失的必要條件，絕非充分條件！這些技術固然重要，但是與之相比，更加重要的是“人”的因素。再優秀的技術，如果沒有人來定期做健康檢查並排查潛在問題的話，這些都是“浮雲”。這裡給大家分享一個最近剛剛為客戶處理完的一個Case。起到警示的作用。

【資料庫環境描述】：
資料庫型別：    某政府核心生產系統
影響範圍：      全國性
資料量：        8T
主機型別：      IBM 570
資料庫版本：    10.2.0.4.0
ASM版本：       10.2.0.4.0
資料庫架構方式：兩節點RAC架構方式；儲存使用ASM技術，並且ASM磁碟頭沒有備份；未部署Data Guard災備站點；歸檔模式，使用RMAN做全庫及增量備份。

【故障現象】：
在手工為表空間新增資料檔案的時候，觸發ASM磁碟頭損壞，ASM的alert日誌中記錄瞭如下資訊：
Sat Jun 9 01:45:51 2012
WARNING: cache read a corrupted block gn=1 dsk=39 blk=18 from disk 39
NOTE: a corrupted block was dumped to the trace file
ERROR: cache failed to read dsk=39 blk=18 from disk(s): 39
ORA-15196: invalid ASM block header [kfc.c:8033] [check_kfbh] [2147483687] [18] [2154781313 != 2634714205]
System State dumped to trace file /home/oracle/admin/+ASM/bdump/+asm1_arb0_602136.trc
NOTE: cache initiating offline of disk 39 group 1
WARNING: offlining disk 39.3734428818 (BDC_DATA_0039) with mask 0x3
NOTE: PST update: grp = 1, dsk = 39, mode = 0x6

【艱難的資料恢復過程】：
第一次嘗試：直接恢復ASM磁碟頭資料
嘗試使用Oracle KFED（Kernel Files Editor）工具修改ASM磁碟頭，如果這種方式能夠順利的恢復ASM磁碟頭的話，將是一種完美的結局，然而事與願違，此時的ASM磁碟頭損壞非一般類型的損壞（故障原因中給出分析），使用KFED無法完成恢復。第一次夢魘不期而遇。

第二次嘗試：使用RMAN進行資料恢復
既然每天都做RMAN的備份，正常情況下便可以使用RMAN進行資料恢復。因此，找來裝置上嘗試資料恢復（提醒：千萬不要在生產環境上嘗試恢復，保留現場很重要！），8T的資料複製以及恢復時間都是不可想象的，經過漫長的17小時的恢復，夢魘再一次來襲，在嘗試恢復的過程中突然發現，RAC的第二節點上的歸檔日誌不完整，僅剩半個月之前的歸檔日誌，這是不可饒恕的，這也就意味著，使用RMAN工具最多隻能恢復到15天前的資料，最近半個月的資料將蕩然無存。這便是典型的“無人值守”導致的災難。

第三次嘗試：盡最大努力挽回資料
由於RAC第二節點歸檔日誌的丟失導致最多可以恢復到15天前的資料，但也不要放棄希望，盡一切努力進行資料恢復。再次嘗試使用RMAN恢復資料到15天前。正如小說中常見的情景，此時，夢魘又一次降臨到這套可憐的資料庫！即便恢復到了15天前的資料，發現資料庫依然無法正常open。嘗試各種手段，啟用隱含引數等方法，亦不奏效。使用各種手段強制open資料庫後alert日誌中頻現ORA-00600錯誤，即使在邏輯匯出資料的過程中，都在頻繁的丟擲 ORA-00600錯誤。最終以備份介質無效無法完美恢復而終止。

第四次終極處理方法：使用工具直接抽取ASM磁碟組中的資料
在客戶幾近崩潰的時候，最終選擇了直接資料抽取方法進行恢復，直接抽取ASM磁碟組中的資料，構造出資料檔案的全貌，又是一個10多小時的漫長資料抽取恢復時間。經過漫長的等待之後，經驗證，資料完美恢復完畢，沒有讓客戶丟失任何一條重要資料！

【故障原因】：
此次故障推測是由於底層磁碟的對映混亂導致的，比如主機重啟後導致disk number變化，導致Oracle認為ASM磁碟組的某塊盤是voting disk，進而錯誤的寫入了心跳資訊，覆蓋了原來位置上的ASM後設資料ALT，這樣一旦有大規模的reblance操作需要改上述ALT時，ASM便出現了上述故障。這種故障是無法透過簡單的KFED工具進行恢復的。

【資料安全故障總結】：
這個Case中的故障本身並不可怕，可怕的是這個過程中出現的各種險情，發人深思。我們經常提到“備份重於一切”、“有備無患”等DBA職業操守。我認為最佳的詮釋應該再加一條：在可信的架構方式下，定期對備份介質進行有效性驗證，及災備環境DRP演練的前提下！

針對此次故障的前因後果，給出以下建議：
1.給出高可用解決方案；建議使用Data Guard技術做遠端災備；
2.RMAN物理備份以及邏輯備份介質，要定期做備份介質有效性驗證；
3.“人”的因素，制定嚴格的備份恢復檢查機制，對備份以及災備環境進行日常檢查；
4.前期的架構設計很重要；
5.……

關於此案例，歡迎訪問itpub論壇參與討論： http://www.itpub.net/thread-1701553-1-1.html

Good luck.

secooler
12.08.03

-- The End --

【資料安全】一次驚心動魄的ASM磁碟頭損壞故障處理過程帶來的深思

相關文章