成功案例

某政府部门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 碎片数据:





修复错误的数据库后进行数据导出:


沪公网安备 31010402007118号