服务器数据恢复环境：
一台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、提取实现数据后由用户方工程师进行验证，通过重复验证，用户方工程师确认复原进去的数据无效。本次数据恢复工作实现。
发表回复