共计 1338 个字符，预计需要花费 4 分钟才能阅读完成。
服务器数据恢复环境：
一台 IBM 某型号服务器，4 块 SAS 磁盘组建了一组 RAID5 磁盘阵列。服务器装置的 windows server 操作系统，下面运行了一个 Oracle 单节点，数据存储为文件系统，无归档。该 oracle 数据库的数据量不大，只有一个用户，应用默认的 users 表空间，users 空间下只有一个不大的数据文件。
服务器故障：
因为服务器超负荷运行，RAID5 磁盘阵列呈现问题。为了保障服务器能失常稳固运行，工作人员做了重建 RAID 的操作，在重建 RAID 过程中因为 RAID 中的一块磁盘呈现故障，RAID 初始化停止，大量数据被同步而毁坏，然而 RAID5 磁盘阵列曾经能够拜访。
服务器操作系统尽管呈现谬误，但还能失常启动。oracle 数据库所在 D 盘分区报错无奈关上，工作人员做了 chkdsk 后能失常关上 D 盘分区，但 oracle 数据库无奈启动。工作人员在 D 盘上重装了 oracle 数据库并导入了以前备份的 dmp 文件，但数据和出故障前的 oracle 数据库数据相差太多。
服务器数据恢复过程：
1、将故障服务器中所有磁盘编号后取出，以只读形式进行全盘镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。
2、基于镜像文件剖析 RAID。因为重建 RAID 会给数据造成重大的毁坏，但通过对底层数据的剖析发现重建的 RAID 的块大小、盘序都和原来的 RAID 统一。在初始化过程中仅同步了后面局部的大量数据，RAID 数据损坏不大，数据库还没被毁坏。
3、Chkdsk 并不会毁坏用户数据区，chkdsk 只对文件系统元数据区进行批改。执行 chkdsk 操作后 oracle 数据库文件没有被毁坏，最多只是文件的 MFT 或目录项被毁坏。真正对数据毁坏重大的操作是重装 Oracle 数据库和导入 dmp 文件，这一系列操作不仅对文件系统元数据区造成了毁坏，还将用户数据区进行了笼罩。
4、基于镜像文件剖析 D 盘的 NTFS 文件系统，发现所有原 oracle 数据文件的 MFT 均被笼罩，NTFS 日志也被轮回笼罩，从 NTFS 元数据区找不到可利用信息。数据恢复工程师只能应用北亚企安自主研发的 Oracle 恢复程序对整个 D 盘分区进行复原。
5、通过程序的扫描，发现 Oracle 实例为 ANSORA，扫描出一个原始残缺的管制文件和一个原始残缺的 undotbs 表空间数据文件。重要的 system 和 users 表空间数据文件都被不同水平的毁坏：其中 system 表空间的数据文件仅剩中后部的十多 MB，原始文件应该约有几百 MB；users 表空间的数据文件有局部被笼罩，仅剩几 MB。提取出找到的数据，而后对损坏重大的数据库进行修复。
6、因为 system 表空间不可用，无奈失去数据字典。通过沟通，用户方确认了有重要的三张表，从 imp 回去的数据库中获取到这三张表的构造，再从复原 users 表空间的数据文件中找到对应的 segment。但有一张表无奈对应上，再次沟通得悉这一张表有过更改字段的操作，北亚企安数据恢复工程师只能从新构建新的表构造对应上 users 表空间数据文件中 segment，而后通过 dul 工具提取这三张表的数据。
7、提取实现数据后由用户方工程师进行验证，通过重复验证，用户方工程师确认复原进去的数据无效。本次数据恢复工作实现。
