北京某敏感政府部门，一中标麒麟Linux平台下DB2 v9.7 数据库，因双机双写，造成存储上的一 EXT4 文件系统严重损坏，有大量的数据被覆盖。

  由于单位性质敏感，加上DB2 不好进行恢复和修复，恢复价格上涨到10余W，客户方表示没问题。

 

 开始事情是由北京一家知名数据恢复公司接手，但恢复了3天，无任何实质性进展。

后由 VMxDB.com 接手。

 从EXT4 文件系统层已找不到有价值的信息，只有从底层进行 DB2 数据库的容器文件的碎片收集和重组，此案例最大的一个容器文件有  22GB, 而且里面有大字段，DB2有大字段在容器底层数据页无规律可言，不过对收集和重组文件碎片影响不大，问题在于大量的数据页被覆盖，用backup方式备份的数据只在去年 11月份，当时此容器才5GB，对 DB2 的修复参考价值不大。

 

把重要的表空间的容器用碎片的方式恢复出来后，使用 DB2数据库本身 已可以正常 activation 和connect  ，但底层大量数据缺失，select 和用 DB2 的数据灾难强制数据导出命令，恢复出来的数据也不多。底层恢复事情差不多完结，只有从修复过程入手。

 

客户方开始走投无路了，不断打IBM 800电话和找各个知名的 DB2 DBA来进行修复，事情开始不计成本了。

 

当然VMxDB.com也没闲着，考虑各种 方案，写程序分解 DB2 Object 的 MAP，尝试重建MAP，以及直接底层解析....

 

经过3天的底层研究， 终于搞明白DB2 对象存储机制和完全的 Page 结构，写程序重建对象MAP，直接跳过坏Page, 对DB2 重要的表数据进行导出。

 

所幸，重要的数据都在。经客户验证，数据没什么问题。

 此案例历时一星期，从存储层到Linux文件系统层再到DB2层 进行了一次完全分解，其中在DB2层研究和处理遇到瓶颈，几乎放弃，最后还是坚持下来，也总算有所回报，看来做技术还是要有颗耐得住寂寞的心。

 

DB2层其实也不复杂，一通百通。

目前的研究成果：就算一个DB2 数据库， SYSCATSPACE 表空间严重损坏或完全丢失和用户表空间严重损坏，坏到只有部分数据页 ，只要提供表结构，也能最大化恢复出DB2数据库的数据。

 

此案例的DB2 空间存储结构：



从底层最大化恢复DB2 碎片数据：





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