南方某市，一大型企业的一套IBM管理系统，该管理系统使用Oracle数据库平台为windows2008，数据库版本为Oracle10.2.0.3 32位。管理员在管理系统中误删除了数据库，导致整个数据库的控制文件、数据文件、日志文件 等数据全部在系统层被删除。 数据库中的数据极其重要，为该公司的核心业务，在删除数据库后，该公司求助于一家数据恢复公司，恢复了半个月数据仍然大量缺失，而且在客户端也无法正常调用恢复的数据库。 最后客户求助 ，希望在最快的时间内完整恢复数据。 下面是尹工对此案例的完整恢复过程。 把客户的存储介质镜像后，分析数据，发现所有的数据都被删除。 但使用常用数据恢复软件仍可正常恢复控制文件和部分数据文件。 恢复出控制文件后，解析控制文件，发现有一个32GB 和一个11GB 的数据文件 不可恢复，下图在 winhex中只能看一个 JTS.DBF 文件，这是32GB的文件，那个 11GB 的文件连MFT都被覆盖。 而在这个32GB的文件在 winhex中显示0字节，这是由 windows的NTFS特性决定的。 NTFS在文件大于4GB或文件碎片过多，出现扩展MFT后，删除的文件将被清空MFT，所以这个 32GB 的 JTS.DBF 文件显示0字节。 这种被清空MFT的文件用一般的数据恢复软件将不可能被恢复。
尹工使用内部 的Oracle碎片级恢复软件在磁盘底层扫描和分析所有Oracle文件的碎片 ： 
软件列出扫描到的碎片，并自动分析碎片所属的文件和文件所属的数据库名、表空间、文件ID等信息。 那个 32GB 的数据文件 在Oracle中创建数据文件时没有使用 'next size' 语句，导致碎片达2100个之巨。 恢复出数据，然后根据控制文件中的信息把文件改名，用 VMxDB.com 的Oracle文件检测校验软件 对所有文件进行块检测，发现数据极其完美，没有一个坏块。
内部 的Oracle环境下直接拉起数据库，数据库没有任何报错。 访问数据也没任何问题，客户端调用也没任何问题。
全系统Oracle环境：(Win、Linux、AIX、HP-UX、 Solaris) Oracle(9i、10g、11g) 环境已搭建完成 。 DB2环境：(Win、Linux、AIX、HP-UX、 Solaris) DB2(v8、v9、v10) 环境已搭建完成 (暂时不支持 z/OS和 i/OS 环境)。 全系统的 Sybase ASE 环境正在搭建中。 |
