用脚本提取MDF案例

 

故障硬盘型号： ST3802110A

出厂日期：

故障现象：

用户的逻辑 D 盘存放有管家婆的数据库，在整理文件时被误删除，已送其它公司做过处理，无果送至本中心

故障分析：

由于用户无法描述库文件名称及大小，只能提供库中某些“关键字”。打算从关键字入手并在找到关键字后确认其所在是否为 MDF 文件页类型，然后再来定位库文件名所在页。在得到库文件名后再来定位库文件名，从而得到整个库链

处理过程：

使用脚本搜索很快定位到关键字所在的页，在经过查找后定位到库文件名，很快确认了库文件名为 SLZM2008.MDF ，由于用户的建库日期为 2008 年使用至 2009 年 11 月 7 日，所以估计其容量不会很大。使用定位库文件名的脚本来定位库文件名，发现了一大堆符合条件的库文件名，感觉不太对（估计是用户对该盘做过多次备份及复制 MDF 的操作），但是还是从最后一个库名中开始搜索库链，很快就得到了一个大约 24.6M 的库文件，重新生成日志但是提示连接中断，经过和几位朋友的沟通确定所提库中可能某个系统表有问题。在修复后可以加载但是日期为 2008 年，看来这个库和用户所描述的不一样！第一次提取失败

在海云的帮助下重新写了定位脚本，经过长达 4 小时的搜索，脚本终于精确定位到了库文件。使用库链脚本搜索很快找到了文件尾，提取出了大小为 34.2M 的 MDF 文件，至此提取结束，经过对比发现库文件无碎片，重新在查询分析器中生成日志文件，这次没有报错，重设库可以看到用户表中的数据了，至此数据恢复成功！

这里要总结的是这次的 MDF 虽然小且没有碎片但是该案例中的操作环境是复杂的，用户对该逻辑盘可能做过多个操作（如生成备份的 BAK 文件或者是复制 MDF 文件），这就造成了有大量的不准确的干扰信息，而第一个定位脚本由于没有考虑到这方面的原因从而导致搜索出大量目标的现象。经过修改后的第二个脚本很好的解决了这个问题，当然缺点还是有的就是速度过于慢，该逻辑盘的大小为 19.5G 搜索竟然用了 4 个小时，如果容量在大，每簇 SEC 再小，那将会是一种痛苦的煎熬！

对于比较小型的 MDF 文件，还是可以通过脚本来实现的，对于大型的带有多个 GAM 页的 MDF 文件脚本处理起来可能就有一点低效了！

在这里在来记录一下该逻辑盘的参数

大小： 19.5G

文件系统： FAT32

每簇 SEC ： 32

 

 

  

 

 

 

               图 2-1  库链脚本生成了大量的页面信息（这个地方得改进，看起来头都大）

    

图 2-2  库链脚本生成了大量的页面信息（这个地方得改进，看起来头都大）

 

图 3 这是用户的表，呵呵奋战一天的结果

 

本文出自 “中国CHS实验室” 博客，谢绝转载！