S5020 光纤存储FC硬盘数据恢复成功案例
本案例详细介绍了服务器存储数据库恢复的过程，包括RAID重组和数据库数据的修复与验证。
背景介绍：
S5020 光纤存储。存储上一共16块FC硬盘，单盘容量600G。存储前面板10号和13号硬盘亮故障灯，存储映射到redhat上的卷挂载不上，业务崩溃。
图一：
作为备份。在根目录下创建了一个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备份。全库备份完成，没有报错。将应用程序连接到数据库，进行应用层面的数据验证。
数据验证结束，数据库修复完成，数据恢复成功。
背景介绍：
S5020 光纤存储。存储上一共16块FC硬盘，单盘容量600G。存储前面板10号和13号硬盘亮故障灯，存储映射到redhat上的卷挂载不上，业务崩溃。
开始工作：
通过storage manager连接到存储查看当前存储状态，存储报告逻辑卷状态失败，再查看物理磁盘状态，发现6号盘报告“警告”，10号和13号盘报告“失败”，通过storage manager将当前存储的完整日志状态备份下来，解析备份出来的存储日志获得了关于逻辑卷结构的部分信息。图一：
将16块FC盘粘贴标签，按照原始槽位号登记后从存储中移除，使用FC盘镜像设备“R510+SUN3510”对16块FC盘进行粗略测试，结果发现16块盘均能正常识别，分别检测16块盘的SMART状态，结果6号盘的SMART状态为“警告”状态和在IBM storage manager中报告一致。
在windows环境下首先将设备识别出来的FC盘在磁盘管理器中标记为脱机状态，从而为原始磁盘提供了一个写保护功能，然后使用软件对原始磁盘进行扇区级别镜像操作，将原始磁盘中的所有物理扇区镜像到逻辑磁盘并以文件形式保存。在镜像过程中发现6号磁盘的镜像速度很慢，结合先前对硬盘SMART状态检测时发现的问题综合判断，6号盘应该存在大量损坏以及不稳定扇区，导致一般应用软件无法对其进行操作。
经过镜像操作后，磁盘已经全部镜像完成，查看日志，发现在storage manager和硬盘SMART状态中均没有报错的1号盘也存在坏道，10号和13号盘均存在大量不规律的坏道分布，根据坏道列表使用软件定位到目标镜像文件分析发现，ext3文件系统的一些关键源数据信息有的已经被坏道所破坏，只能等待6号盘镜像完毕后，通过同一条带进行xor以及根据文件系统上下文关系的方式手动修复被损坏的文件系统。
得到了所有硬盘的物理扇区镜像，在平台下使用软件将所有镜像文件全部展开，根据我们对ext3文件系统的逆向以及日志文件的分析，得到了16块FC盘在存储中的盘序，RAID的块大小，RAID的校验走向和方式等信息，于是尝试通过软件的方式虚拟重组RAID，RAID搭建完成后进一步解析ext3文件系统，通过和用户沟通提取出了一些oracle的dmp文件，用户尝试进行恢复。
数据库恢复流程
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备份。全库备份完成，没有报错。将应用程序连接到数据库，进行应用层面的数据验证。
数据验证结束，数据库修复完成，数据恢复成功。