【物理服务器与逻辑存储介绍】
客户使用一台IBM 3850服务器，4块300GB SAS磁盘做的RAID5磁盘阵列。服务器操作系统为 windows2003 x64，跑有一个单节点Oracle，版本为11.2.0.2 ，数据存储为文件系统，无归档。此oracle数据量不大，oracle 内只有一个用户建的用户，使用默认的users 表空间，users 表空间下仅有一个数据文件，大小不到 1GB。

【服务器故障现象】
由于负荷过重，存储底层的RAID磁盘阵列出现问题，用户为了挽救数据做了一系列重建RAID的操作，后因一磁盘出现故障而中止RAID初始化，但有少量数据被同步而破坏，此时RAID磁盘阵列已可访问，
系统虽出现错误，但能正常启动，但D盘也就是oracle数据库所在分区报错无法打开，客户chkdsk后能正常打开，但oracle无法启动，客户在原盘上重装了 oracle系统，并导入了以前备份的 dmp文件，但数据差得太多。

【数据恢复过程】
客户联系到北京数据恢复中心后，数据恢复中心安排Oracle数据恢复工程师和服务器数据恢复工程师同时来到客户现场进行恢复。
·
首先分析RAID层： 重建RAID会带来最为严重的破坏，但分析发现重建的RAID的块大小、盘序都和原来一样，而在初始化过程中仅同步了前部的少量数据，RAID层损坏不大，数据库还没被破坏。
·
然后分析后面管理员对分区chkdsk和重装oracle系统和导入 dmp文件所带来的破坏： Chkdsk并不会破坏用户数据区，chkdsk只对文件系统元数据区修改。这时数据库文件仍无破坏，最多只是文件的MFT或目录项被破坏。最严重的是重装 Oracle系统和导入dmp文件，这不只是对 文件系统元数据区进行破坏，还对用户数据区进行覆盖。
·
第三步对D盘的NTFS文件系统进行分析：发现原所有oracle数据文件的的MFT均被覆盖，NTFS日志也早被轮回覆盖，从NTFS元数据区找不可利用信息。只能使用数据恢复中心内部的Oracle恢复程序对整个分区进行恢复。经扫描，发现 Oracle实例为 ANSORA，扫描出的一个原始完整的控制文件和一个原始完整的undotbs表空间数据文件，重要的system和 users表空间数据文件都有不同程度的破坏，
·
其中system表空间的数据文件仅剩中后部的10MB，原始应有约700MB，而 users 表空间的数据文件也有部分被覆盖，但仅4MB。
提取出找到了数据，下一步对严重损坏的数据库进行修复。
·
由于 system表空间不可用，无法得到数据字典，在和客户沟通后，客户确认了重要的三张表，这三张表也较大，从客户imp回去的数据库中得到了这三张表的结构，再从恢复 users表空间的数据文件中找到对应的segment，但有一张表死活无法对应上，再次询问客户，客户表示这一张表有过更改字段的操作，再构建新的表结构对应上users表空间数据文件中segment，然后通过 oracle官方的dul工具提取这三张表的数据，客户验证后，表示数据已无问题。

【数据恢复结果】耗时三天，用户指定数据99%以上恢复成功。