成功案例

某政府部門Linux下DB2數據庫數據恢復案例

2018-08-11 14:52:15
北京某敏感政府部門,一中標麒麟Linux平臺下DB2 v9.7 數據庫,因雙機雙寫,造成存儲上的一 EXT4 文件系統嚴重損壞,有大量的數據被覆蓋。
由于單位性質敏感,加上DB2 不好進行恢復和修復,恢復價格上漲到10余W,客戶方表示沒問題。
開始事情是由北京一家知名數據恢復公司接手,但恢復了3天,無任何實質性進展。
后由凌治數據恢復中心接手。
從EXT4 文件系統層已找不到有價值的信息,只有從底層進行 DB2 數據庫的容器文件的碎片收集和重組,此案例最大的一個容器文件有  22GB, 而且里面有大字段,DB2有大字段在容器底層數據頁無規律可言,不過對收集和重組文件碎片影響不大,問題在于大量的數據頁被覆蓋,用backup方式備份的數據只在去年 11月份,當時此容器才5GB,對 DB2 的修復參考價值不大。
把重要的表空間的容器用碎片的方式恢復出來后,使用 DB2數據庫本身 已可以正常 activation 和connect  ,但底層大量數據缺失,select 和用 DB2 的數據災難強制數據導出命令,恢復出來的數據也不多。底層恢復事情差不多完結,只有從修復過程入手。
客戶方開始走投無路了,不斷打IBM 800電話和找各個知名的 DB2 DBA來進行修復,事情開始不計成本了。
當然凌治數據恢復中心也沒閑著,考慮各種 方案,寫程序分解 DB2 Object 的 MAP,嘗試重建MAP,以及直接底層解析....
經過3天的底層研究, 終于搞明白DB2 對象存儲機制和完全的 Page 結構,寫程序重建對象MAP,直接跳過壞Page, 對DB2 重要的表數據進行導出。
所幸,重要的數據都在。經客戶驗證,數據沒什么問題。
此案例歷時一星期,從存儲層到Linux文件系統層再到DB2層 進行了一次完全分解,其中在DB2層研究和處理遇到瓶頸,幾乎放棄,最后還是堅持下來,也總算有所回報,看來做技術還是要有顆耐得住寂寞的心。
DB2層其實也不復雜,一通百通。
目前的研究成果:就算一個DB2 數據庫, SYSCATSPACE 表空間嚴重損壞或完全丟失和用戶表空間嚴重損壞,壞到只有部分數據頁 ,只要提供表結構,也能最大化恢復出DB2數據庫的數據。
此案例的DB2 空間存儲結構:



從底層最大化恢復DB2 碎片數據:





修復錯誤的數據庫后進行數據導出:


内蒙古十一选五贴吧