共计 3064 个字符，预计需要花费 8 分钟才能阅读完成。
背景介绍：
IBM DS5020 光纤存储。存储上一共 16 块 FC 硬盘，单盘容量 600G。存储前面板 10 号和 13 号硬盘亮 *** 故障灯，存储映射到 RedHat 上的卷挂载不上，业务崩溃。
开始工作：
通过 IBM storage manager 连接到存储查看当前存储状态，存储报告逻辑卷状态失败，再查看物理磁盘状态，发现 6 号盘报告“警告”，10 号和 13 号盘报告“失败”，通过 IBM storage manager 将当前存储的完整日志状态备份下来，解析备份出来的存储日志获得了关于逻辑卷结构的部分信息。
将 16 块 FC 盘粘贴标签，按照原始槽位号登记后从存储中移除，使用北亚数据恢复的 FC 盘镜像设备“DELL R510+SUN3510”对 16 块 FC 盘进行粗略测试，结果发现 16 块盘均能正常识别，分别检测 16 块盘的 SMART 状态，结果 6 号盘的 SMART 状态为“警告”状态和在 IBM storage manager 中报告一致。
在 windows 环境下首先将设备识别出来的 FC 盘在磁盘管理器中标记为脱机状态，从而为原始磁盘提供了一个写保护功能，然后使用 winhex 软件对原始磁盘进行扇区级别镜像操作，将原始磁盘中的所有物理扇区镜像到 windows 系统下的逻辑磁盘并以文件形式保存。在镜像过程中发现 6 号磁盘的镜像速度很慢，结合先前对硬盘 SMART 状态检测时发现的问题综合判断，6 号盘应该存在大量损坏以及不稳定扇区，导致在 windows 下的一般应用软件无法对其进行操作。
使用专业坏道硬盘镜像设备对 6 号硬盘进行坏道镜像操作，在镜像过程中同时观察镜像的速度和稳定性，发现 6 号盘的坏道并不多，但是存在大量的读取响应时间长等不稳定扇区，于是调整 6 号盘的拷贝策略，将遇到坏道跳过扇区数和响应等待时间等参数均作一些修改。继续对 6 号盘进行镜像操作。同时观察剩余盘在 windows 环境下使用 winhex 镜像的情况。
经过镜像操作后，在 windows 平台下使用 winhex 镜像的磁盘已经全部镜像完成，查看 winhex 生成的日志，发现在 IBM storage manager 和硬盘 SMART 状态中均没有报错的 1 号盘也存在坏道，10 号和 13 号盘均存在大量不规律的坏道分布，根据坏道列表使用 winhex 定位到目标镜像文件分析发现，ext3 文件系统的一些关键源数据信息有的已经被坏道所破坏，只能等待 6 号盘镜像完毕后，通过同一条带进行 xor 以及根据文件系统上下文关系的方式手动修复被损坏的文件系统。
坏道镜像设备报告 6 号盘镜像完成，但是先前为了最大限度做出有效扇区以及为了保护磁头设置的拷贝策略会自动跳过一些不稳定扇区，所以现在的镜像是不完整的，于是调整拷贝策略，继续镜像被跳过的扇区，6 号盘所有扇区全部镜像完毕。
得到了所有硬盘的物理扇区镜像，在 windows 平台下使用 winhex 将所有镜像文件全部展开，根据我们对 ext3 文件系统的逆向以及日志文件的分析，得到了 16 块 FC 盘在存储中的盘序，RAID 的块大小，RAID 的校验走向和方式等信息，于是尝试通过软件的方式虚拟重组 RAID，RAID 搭建完成后进一步解析 ext3 文件系统，通过和用户沟通提取出了一些 Oracle 的 dmp 文件，用户尝试进行恢复。
在 dmp 恢复的过程中，oracle 报告为 imp-0008 错误，联系北亚的 oracle 工程师，通过仔细分析导入 dmp 文件的日志文件，发现恢复的 dmp 文件存在问题而导致 dmp 导入数据失败。立刻重新分析 raid 结构，以及进一步确定 ext3 文件系统被破坏的程度，又经过数小时的工作，重新恢复 dmp 文件和 dbf 原始库文件，将恢复出来的 dmp 文件移交给用户进行数据导入测试，结果测试顺利没有发现问题，说明这次的数据恢复是成功的，接着对恢复出来的 dbf 原始库文件进行校验检测，所有文件均能通过测试。
北亚的数据库工程师到达现场，和用户沟通后决定使用恢复出来的 dbf 原始库文件进行操作，以确保能把数据恢复到最佳状态。
数据库恢复流程
1. 拷贝数据库文件到原数据库服务器，路径为 /home/oracle/tmp/syntong.
作为备份。在根目录下创建了一个 oradata 文件夹，并把备份的整个 syntong 文件夹拷贝到 oradata 目录下。然后更改 oradata 文件夹及其所有文件的属组和权限。
2. 备份原数据库环境，包括 ORACLE_HOME 下 product 文件夹下的相关文件。配置监听，使用原机中的 splplus 连接到数据库。尝试启动数据库到 nomount 状态。进行基本状态查询后，了解到环境和参数文件没有问题。尝试启动数据库到 mount 状态，进行状态查询没有问题。启动数据库到 open 状态。出现报错：
ORA-01122: databasefile 1 failed verification check
ORA-01110: data file1: ‘/oradata/syntong/system01.dbf’
ORA-01207: file ismore recent than control file – old control file
3. 经过进一步的检测和分析，判断此故障为控制文件和数据文件信息不一致，这是一类因断电或突然关机等引起的常见故障。
4. 对数据库文件进行逐个检测，检测到所有数据文件没有物理损毁。
5. 在 mount 状态下，对控制文件进行备份，alter database backupcontrolfile to trace as ‘ /backup/controlfile’；对备份的控制文件进行查看修改，取得其中的重建控制文件命令。把这些命令复制到一个新建脚本文件 controlfile.sql 中。
6. 关闭数据库，删除 /oradata/syntong/ 下的 3 个控制文件。启动数据库到 nomount 状态，执行 controlfile.sql 脚本。
SQL>startupnomount
SQL>@controlfile.sql
7. 重建控制文件完成后，直接启动数据库，报错，需要进一步处理。
SQL> alterdatabase open;
alter database open
*
ERROR at line 1:
ORA-01113: file 1needs media recovery
ORA-01110: data file1: ‘/free/oracle/oradata/orcl/system01.dbf’
然后执行恢复命令：
recover databaseusing backup controlfile until cancel;
Recovery of OnlineRedo Log: Thread 1 Group 1 Seq 22 Reading mem 0
Mem# 0 errs 0:/free/oracle/oradata/orcl/redo01.log
…
做介质恢复，直到返回报告，恢复完成。
8. 尝试 open 数据库。
SQL> alterdatabase open resetlogs;
9. 数据库启动成功。把原来 temp 表空间的数据文件加入到对应的 temp 表空间中。
10. 对数据库进行各种常规检查，没有任何错误。
11. 进行 emp 备份。全库备份完成，没有报错。将应用程序连接到数据库，进行应用层面的数据验证。
数据验证结束，数据库修复完成，数据恢复成功。
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-02/140992.htm
