最近接觸了幾則客戶的oracle數據庫恢復案例,記錄一下供大家參考。

案例一：
某客戶為了重新部署系統，將數據導出備份到移動硬盤，然后將Raid重新格式化，重新安裝系統，當進行Oracle數據庫重建，導入數據時發現，移動硬盤上的數據無法正確讀取，文件缺失一半。數據災難形成。

導入數據時出現　IMP-00009　錯誤，和以下文章描述的狀況是相同的：
我到現場進行分析，發現文件的確只復制了一半，丟失了大約２００張數據表的數據。通過備份恢復數據已經不可能。
最后只有一種方式，就是從被格式化的硬盤上進行碎片重組，找回數據，最終這條路成功了，通過硬盤恢復找回數據恢復了業務運行。


這個案例給我們的提示是：重要數據，備份需要多留拷貝，在進行備份驗證之前，備份的可靠性不能輕信。

ASM，它能夠直接從ASM磁盤中解析數據。即使由于硬件或錯誤地FORMAT導致ASM磁盤頭部數據損壞而導致ASM磁盤組不能加載時，DATA-LADR仍然能夠從ASM中恢復數據。正是由于DATA-LADR的這一特性，現在在ASM里恢復被誤Truncate掉的表中的數據將變得輕而易舉。

下面我利用DATA-LADR 4.1.2的試用版來演示如何在Oracle 11gR2 ASM中恢復被誤Truncate掉的表中的數據。

請注意——DATA-LADR試用版僅用于測試、學習和驗證，只能恢復SYSTEM表空間下的數據，對于其他表空間的數據，僅恢復少量的數據以驗證數據可恢復。而正式版在獲取LICENSE后能夠恢復所有能夠恢復的數據。

準備好DATA-LADR所需要的控制文件
案例二：
某用戶，SUN的存儲陣列，已經持續運行了７年，最后存儲的Raid中，同時損壞了兩塊硬盤，熱備盤早已損壞，但是由于存儲所有的綠燈都亮，用戶一直以為存儲正常無故障運行。

此次故障出現，存儲罷工，數據庫服務無法提供，用戶沒有備份。

我們到現場，只有一個途徑，就是通過存儲級別恢復數據，找回文件，雖然磁盤出現故障，但是數據仍然是完好的，通過計算奇偶校驗，回復數據，然后最終修復啟動了數據庫，在數據庫級別存在壞塊，不一致，通過BBED，隱含參數等，可以成功打開數據庫。

這個案例給我們的提示是：硬件和人一樣，過勞都會出現災難，請大家注意健康。

在微博上，有朋友說，硬件總會出問題，要多監控就應當能夠及時預警，我的觀點是：
再嚴密的部門，再嚴密的監控，總有疏忽，這樣的疏忽，有很多大牛的公司都犯過，我們也經歷過，所以大家應當共同警示吧。細心多一萬分不多，粗心就一次致命。

案例三：
某用戶，構建大型的ERP系統，在部署初始化環境時，由于疏忽，在安裝數據庫時，覆蓋了原有的一個重要數據庫。形成數據災難。

對于這類操作，通常覆蓋的只是SYSTEM表空間、UNDO表空間、Users表空間等，數據表空間通常不會覆蓋，但是如果數據結構復雜，通過DUL等工具去抽取數據會根本不可實現。