服务器数据恢复IBM存储服务器硬盘坏道离线oracle数据库损坏的数据恢复案例

Posted 宋国建

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了服务器数据恢复IBM存储服务器硬盘坏道离线oracle数据库损坏的数据恢复案例相关的知识,希望对你有一定的参考价值。

服务器数据恢复环境:

IBM某型号存储服务器;

16块单盘容量600G的FC硬盘。


服务器故障:

指向10号和13号硬盘的指示灯显示为黄色;

存储映射到redhat上的卷挂载不上,业务中断。

【服务器数据恢复】IBM存储服务器硬盘坏道离线、oracle数据库损坏的数据恢复案例_数据库

存储服务器数据恢复过程:

1、通过IBM storage manager连接到服务器上查看当前存储状态:服务器报告逻辑卷状态失败,6号盘报告“警告”,10号和13号盘报告“失败”。

2、通过IBM storage manager将当前存储的完整日志状态备份下来,解析备份出来的存储日志获取关于逻辑卷结构的部分信息。

3、服务器数据恢复工程师将16块FC盘做好标记,按照原始槽位号登记后把这16块FC硬盘从存储中取出。使用数据恢复使用的FC盘镜像设备对16块FC盘进行粗略测试,均能正常识别;对16块盘的SMART状态进行检测,6号盘的SMART状态为“警告”,和在IBM storage manager中报告一致。

4、数据恢复工程师在windows环境下将设备识别出来的FC盘在磁盘管理器中标记为脱机状态,对原始磁盘写保护。然后对原始磁盘进行扇区级别镜像备份,将原始磁盘中的所有物理扇区镜像到windows系统下的逻辑磁盘并以文件形式保存。镜像过程中6号磁盘的镜像速度不正常,结合之前6号磁盘的SMART状态,可以判断6号盘存在损坏和不稳定扇区。

5、使用坏道硬盘专用镜像设备对6号硬盘进行备份,发现6号盘的坏道不多,但是存在大量读取响应时间长的不稳定扇区。调整拷贝策略对6号盘进行镜像备份。

6、完成所有磁盘镜像后,对生成的日志进行分析,发现在IBM storage manager和硬盘SMART状态中均没有报错的1号盘存在坏道,10号和13号盘均存在大量不规律的坏道分布。根据坏道列表定位到目标镜像文件,发现ext3文件系统的部分关键源数据信息由于坏道已经被破坏,只能等待6号盘镜像完毕后,通过同一条带进行xor以及根据文件系统上下文关系手动修复损坏的文件系统。

7、虽然坏道镜像设备对6号盘的镜像完成,但是先前的拷贝策略会自动跳过一些不稳定扇区,所以做出来的镜像是不完整的,调整拷贝策略,继续镜像被跳过的扇区,完成6号盘所有扇区的镜像。

【服务器数据恢复】IBM存储服务器硬盘坏道离线、oracle数据库损坏的数据恢复案例_数据库_02

8、完成所有硬盘镜像后,根据对ext3文件系统的逆向以及日志文件的分析,获取到16块FC盘在存储中的盘序,RAID的块大小,RAID的校验走向和方式等信息。利用获取到的信息虚拟重组RAID,完成RAID搭建后进一步解析ext3文件系统,通过和服务器管理员沟通提取出了一些oracle的dmp文件,尝试利用dmp文件进行数据恢复。

9、在利用dmp文件进行数据恢复的过程中,oracle报告imp-0008错误。北亚的oracle工程师通过分析导入dmp文件的日志文件,发现恢复出来的dmp文件存在问题。

10、重新分析raid结构,进一步确定ext3文件系统被破坏的程度。经过数小时的努力,重新恢复出来dmp文件和dbf原始库文件,将恢复出来的dmp文件进行数据导入测试,没有出现问题,证明了这次恢复出来的数据是没有问题的。

11、对恢复出来的dbf原始库文件进行校验检测,所有文件均能通过测试。

12、和服务器管理员进行沟通后,最终决定使用恢复出来的dbf原始库文件进行数据恢复。


数据库恢复流程:

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

【服务器数据恢复】IBM存储服务器硬盘坏道离线、oracle数据库损坏的数据恢复案例_数据恢复_03

2.备份原数据库环境,包括ORACLE_HOME下product文件夹下的相关文件。配置监听,使用原机中的splplus连接到数据库。尝试启动数据库到nomount状态。进行状态查询发现环境和参数文件没有问题。 尝试启动数据库到mount状态,进行状态查询没有问题。启动数据库到open状态。出现报错:

ORA-01122: database file 1 failed verification check/frombyte.com

ORA-01110: data file 1: /oradata/syntong/system01.dbf

ORA-01207: file is more recent than control file - old control file

经过进一步的检测和分析,判断此故障为控制文件和数据文件信息不一致,这是一类因断电或突然关机等引起的常见故障。

3、对数据库文件逐个检测,检测到所有数据文件没有物理损坏。

4、在mount状态下对控制文件进行备份,alter database backup controlfile to trace as /backup/controlfile。对备份的控制文件进行查看修改,取得其中的重建控制文件命令。把这些命令复制到一个新建脚本文件controlfile.sql中。

5、关闭数据库,删除/oradata/syntong/下的3个控制文件。 启动数据库到nomount状态,执行controlfile.sql 脚本。

SQL>startup nomount/frombyte.com

SQL>@controlfile.sql

6、重建控制文件完成后,启动数据库报错,需要进一步处理。

SQL> alter database open;

alter database open/frombyte.com

*

ERROR at line 1:

ORA-01113: file 1 needs media recovery

ORA-01110: data file 1: /free/oracle/oradata/orcl/system01.dbf

然后执行恢复命令:

recover database using backup controlfile until cancel;

Recovery of Online Redo Log: Thread 1 Group 1 Seq 22 Reading mem 0

Mem# 0 errs 0: /free/oracle/oradata/orcl/redo01.log


做介质恢复,直到返回报告,恢复完成。

7、尝试open数据库。

SQL> alter database open resetlogs;

8、数据库启动成功。把原来temp表空间的数据文件加入到对应的temp表空间中。

9、对数据库进行各种常规检查,没有任何错误。

10、进行emp备份。全库备份完成,没有报错。将应用程序连接到数据库,进行应用层面的数据验证。

以上是关于服务器数据恢复IBM存储服务器硬盘坏道离线oracle数据库损坏的数据恢复案例的主要内容,如果未能解决你的问题,请参考以下文章

北亚数据恢复IBM3650服务器raid5硬盘故障离线rebuild过程中遭遇坏道导致服务器崩溃的数据恢复

服务器数据恢复HP EVA系列存储硬盘离线导致LUN丢失不可用的数据恢复案例

IBM ds4700存储硬盘离线数据恢复-北亚案例

IBM DS5300存储数据恢复由于硬盘坏道导致RAID5崩溃的数据恢复案例

服务器数据恢复IBM某型号存储热备盘同步数据过程中硬盘离线导致RAID5崩溃的数据恢复案例

IBM服务器多块硬盘离线数据恢复方法