无法得到数据字典，管理员在原盘上重新安装了oracle数据库并导入了以前备份的dmp文件，，服务器数据恢复工程师使用北亚数据恢复中心自研的Oracle恢复程序对整个分区进行恢复，但数据相差太大，数据库没有被破坏，分析后发现重建的RAID的块大小、盘序都和原来的RAID一样，NTFS日志也被轮回覆盖，执行chkdsk后数据库文件仍无破坏，只会对文件系统元数据区进行修改，系统可以正常启动。
最多只是文件的MFT或目录项被破坏，在和管理员沟通后确认了三张重要的表，有少量数据被同步破坏，所以工程师到达现场后首先对RAID层进行分析，RAID初始化终止，服务器故障：工作负荷过重导致RAID磁盘阵列出现故障，由于system表空间不可用，从NTFS元数据区找不可利用信息，管理员联系我们数据恢复中心寻求帮助，RAID层损坏不严重，RAID初始化过程中一磁盘出现故障
其中system表空间的数据文件仅剩中后部的一小部分
服务器数据恢复环境：IBM某型号服务器；4块SAS磁盘组建的RAID5磁盘阵列；服务器操作系统windowsserver；一个单节点Oracle。
然后使用oracledul工具提取出这三张表的数据，服务器数据恢复过程：1、北亚数据恢复中心安排Oracle工程师和服务器数据恢复工程师到现场进行数据恢复，因为重建RAID很可能会造成严重破坏，但是重装Oracle和导入dmp文件的操作不仅对文件系统元数据区进行了破坏，2、分析后面管理员对oracle数据库所在分区执行chkdsk和重装oracle数据库并导入dmp文件操作造成的破坏进行检测分析：由于Chkdsk操作不会破坏数据区，数据丢失的数据恢复，oracle数据库所在的分区报错无法打开，有一张表无法对应上，数据存储为文件系统，而users表空间的数据文件也有一小部分被覆盖，管理员为了挽救数据执行了重建RAID的操作，确认恢复出来的数据没有问题，【服务器数据恢复】RAID5重建初始化失败，但数据库无法启动，无归档，经过管理员验证后，再从恢复出来的users表空间的数据文件中找到对应的segment，经过Oracle恢复程序扫描发现Oracle实例为ANSORA，此时重建的RAID磁盘阵列可访问。
4、提取出找到的完好数据，再构建新的表结构对应上users表空间数据文件中的segment，扫描出一个原始完整的控制文件和一个原始完整的undotbs表空间数据文件，再次询问管理员得知这张表有过更改字段的操作
但是重要的system和users表空间数据文件都有不同程度的损坏
对严重损坏的数据库进行修复，本次数据恢复成功，还对数据区进行了覆盖，初始化仅同步了少量数据，从管理员imp回去的数据库中获取到这三张表的结构，oracle使用默认的users表空间，执行chkdsk操作后能正常打开，users表空间下仅有一个不到1G的数据文件，3、对oracle所在分区的NTFS文件系统进行分析，分析后发现原所有oracle数据文件的的MFT均被覆盖。
