服务器数据恢复环境：

IBM DS系列存储服务器；
16块容量600G的FC硬盘。

故障：

存储服务器前面板10号和13号硬盘故障灯亮，存储映射到redhat上的卷挂载不上，业务下线。服务器管理员分割北亚数据恢复核心进行服务器数据恢复。

服务器数据备份和测试过程：

1、到现场后，北亚数据恢复工程师通过storage manager连贯到存储查看以后存储状态，存储报告逻辑卷状态失败。物理磁盘状态：6号盘报告“正告”，10号和13号盘报告“失败”。

2、通过storage manager将以后存储的残缺日志备份下来，通过解析备份进去的存储日志，北亚数据恢复工程师获取了对于逻辑卷构造的局部信息。

3、将16块FC盘粘贴标签，依照原始槽位号注销后从存储中移除，应用FC盘镜像设施“R510+SUN3510”对16块FC盘进行粗略测试，16块盘均能失常辨认。别离检测16块盘的SMART状态，发现6号盘的SMART状态为“正告”，和在IBM storage manager中报告统一。

4、在windows环境下将设施辨认进去的FC盘在磁盘管理器中标记为脱机状态，为原始磁盘提供一个写爱护性能。北亚数据恢复工程师而后应用软件对原始磁盘进行扇区级别镜像操作，将原始磁盘中的所有物理扇区镜像到逻辑磁盘并以文件模式保留。在镜像过程中发现6号磁盘的镜像速度很慢，联合先前对硬盘SMART状态检测时发现的问题综合判断，6号盘应该存在大量损坏以及不稳固扇区，导致个别应用软件无奈对其进行操作。

5、应用坏道硬盘镜像设施对6号硬盘进行坏道镜像操作，在镜像过程中同时观察镜像的速度和稳定性，发现6号盘的坏道并不多，然而存在大量的读取响应工夫长的不稳固扇区。于是北亚数据恢复工程师调整6号盘的拷贝策略，将“遇到坏道跳过扇区数”和“响应等待时间”等参数做批改后持续对6号盘进行镜像操作。同时察看残余盘镜像的状况。

6、实现全副镜像后查看日志，发现在storage manager和硬盘SMART状态中均没有报错的1号盘也存在坏道，10号和13号盘均存在大量不法则的坏道散布，通过应用软件定位到指标镜像文件剖析坏道列表发现，ext3文件系统的局部要害源数据信息曾经被坏道毁坏，只能期待6号盘镜像结束后，通过同一条带进行xor以及依据文件系统上下文关系的形式手动修复被损坏的文件系统。

7、6号盘镜像实现，然而先前为了最大限度备份出无效扇区以及为了爱护磁头设置的拷贝策略会主动跳过一些不稳固扇区，所以当初的镜像是不残缺的。北亚数据恢复工程师调整拷贝策略，持续镜像被跳过的扇区，实现6号盘所有扇区的全副镜像。

8、失去了所有硬盘的物理扇区镜像，在平台下应用软件将所有镜像文件全副开展，依据对ext3文件系统的逆向以及日志文件的剖析，北亚数据恢复工程师获取到了16块FC盘在存储中的盘序、RAID的块大小、RAID的校验走向和形式等信息。北亚数据恢复工程师尝试通过软件的形式虚构重组RAID，RAID搭建实现后进一步解析ext3文件系统，通过和服务器管理员沟通提取出了一些oracle的dmp文件，服务器管理员尝试进行复原。

9、在dmp复原的过程中，数据库报告imp-0008谬误，通过仔细分析导入dmp文件的日志文件，北亚数据恢复工程师发现复原的dmp文件存在问题所以导致dmp导入数据失败。北亚数据恢复工程师立即从新剖析raid构造，进一步确定ext3文件系统被毁坏的水平。通过数小时的致力，从新复原dmp文件和dbf原始库文件，将复原进去的dmp文件移交给服务器管理员进行数据导入测试，测试没有发现问题。而后对复原进去的dbf原始库文件进行校验检测，所有文件均能通过测试。

服务器数据库复原流程：

1、 拷贝数据库文件到原数据库服务器，门路为/home/oracle/tmp/syntong作为备份。在根目录下创立了一个oradata文件夹，把备份的整个syntong文件夹拷贝到oradata目录下，而后更改oradata文件夹及其所有文件的属组和权限。

2、备份原数据库环境，包含ORACLE_HOME下product文件夹下的相干文件。配置监听，应用原机中的splplus连贯到数据库。尝试启动数据库到nomount状态。进行根本状态查问后，确认环境和参数文件没有问题。 尝试启动数据库到mount状态，进行状态查问没有问题。启动数据库到open状态。呈现报错：

3、通过进一步的检测和剖析，北亚数据恢复工程师判断此故障为管制文件和数据文件信息不统一，这是一类因断电或忽然关机等引起的常见故障。

4、对数据库文件进行一一检测，检测到所有数据库文件没有物理损毁。

5、在mount状态下，北亚数据恢复工程师对管制文件进行备份，alter database backup controlfile to trace as ' /backup/controlfile'；对备份的管制文件进行查看批改，获得其中的重建管制文件命令。把这些命令复制到一个新建脚本文件controlfile.sql中。

6、 敞开数据库，删除/oradata/syntong/下的3个管制文件。 启动数据库到nomount状态，执行controlfile.sql 脚本。

7、重建管制文件实现后，间接启动数据库，报错，须要进一步解决。

而后执行复原命令：

做介质复原，直到返回报告，复原实现。

8、尝试open数据库。
SQL> alter database open resetlogs;

9、  数据库启动胜利。把原来temp表空间的数据文件退出到对应的temp表空间中。

10、对数据库进行各种惯例查看，没有任何谬误。

11、进行emp备份。全库备份实现，没有报错。将应用程序连贯到数据库，进行利用层面的数据验证。

12、数据验证完结，数据库修复实现，数据恢复胜利。