共计 2360 个字符，预计需要花费 6 分钟才能阅读完成。
服务器数据恢复环境：
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、数据验证完结，数据库修复实现，数据恢复胜利。