Chinaunix首页 | 论坛 | 博客
  • 博客访问: 354193
  • 博文数量: 608
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 6115
  • 用 户 组: 普通用户
  • 注册时间: 2016-08-02 14:16
文章分类

全部博文(608)

文章存档

2024年(172)

2023年(218)

2022年(181)

2020年(12)

2019年(24)

我的朋友

分类: 服务器与存储

2024-07-04 10:59:44

服务器存储数据恢复环境&故障:
一台某品牌DS4700存储中有14块硬盘组建raid,存放的是oracle数据库。存储中有两块硬盘的指示灯亮黄色,raid崩溃,卷无法挂载,业务全部瘫痪。


服务器存储故障检测:
服务器数据恢复工程师通过IBM storage manager连接存储查看服务器存储的当前状态,发现逻辑卷状态失败。对物理磁盘状态进行查看,发现13号磁盘状态为“警告”,10号和11号磁盘状态为“失败”。通过IBM storage manager对当前存储的全部日志进行备份并解析逻辑卷结构信息。


服务器存储数据恢复过程:
1、将服务器存储中全部磁盘编号后取出槽位,由硬件工程师进行物理故障检测。经过初步检测,所有硬盘均可以正常识别,13号盘SMART状态为“警告”,和在IBM storage manager中的状态一致。
2、服务器数据恢复工程师在windows环境下的磁盘管理器中将可以识别的磁盘标记为脱机状态,使用工具将所有磁盘进行扇区级别镜像操作(在镜像过程中13号硬盘的镜像速度极其缓慢,初步判断该盘存在坏道或者不稳定/损坏扇区,需要使用专业设备处理)。在使用专业设备对13号硬盘做镜像的过程中观察镜像状态,发现13号盘的坏道并不多,只是存在大量不稳定扇区。调整该磁盘的镜像策略后继续镜像。镜像完成后将所有磁盘按照编号还原到原存储中。后续的数据分析和数据恢复操作都基于镜像文件进行,避免对原始磁盘数据造成二次破坏。
3、基于镜像文件查看生成的日志,发现在IBM storage manager和硬盘SMART状态中均没有发现异常的1号盘、10号和11号盘均存在大量不规律的坏道分布。结合坏道列表情况进行分析,EXT3文件系统中的部分关键性源数据处于坏道区域,北亚企安数据恢复工程师通过13号硬盘的镜像文件进行同一条带的xor,
并根据文件系统的上下关系手动修复损坏的文件系统。
4、通过对ext3文件系统的逆向以及日志文件的分析获取到盘序、raid校验方向、raid块大小、raid校验方式等信息,利用获取到的信息虚拟重组raid。重组完成后解析EXT3文件系统,将oracle数据库中的dmp文件进行部分提取。
5、在恢复dmp的过程中出现内容为“imp-0008”的报错,经过分析发现报错原因是dmp文件有问题。再次重组raid并重新导出dmp文件和dbf原始库文件进行测试,dbf原始库文件均能通过测试。
6、把数据库文件拷贝到原数据库服务器中,路径为“/home/oracle/tmp/syntong”。在根目录下创建一个oradata文件夹,把整个syntong文件夹拷贝到oradata目录下,更改oradata文件夹及其所有文件的属组和权限。
7、备份原数据库环境,包括ORACLE_HOME下product文件夹下的相关文件。配置监听,使用splplus连接到数据库,尝试启动数据库到nomount状态。进行状态查询没有发现环境和参数文件有问题。 尝试启动数据库到mount状态,进行状态查询没有问题。启动数据库到open状态。出现报错:
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/oradata/syntong/system01.dbf'
ORA-01207: file is more recent than control file - old control file
经过检测和分析,判断此故障为控制文件和数据文件信息不一致,这是一种常见的由于异常关机所引起的故障。
8、对数据库文件进行逐个检测,经过检测没有发现有数据库文件存在物理损毁的情况。
9、在mount状态下备份控制文件,alter database backup controlfile to trace as ' /backup/controlfile';对备份的控制文件进行查看修改,获取到其中的重建控制文件命令。把这些命令复制到一个新建脚本文件controlfile.sql中。
10、关闭数据库,删除/oradata/syntong/下的3个控制文件。 启动数据库到nomount状态,执行controlfile.sql 脚本。
SQL>startup nomount
SQL>@controlfile.sql
11、重建控制文件后,直接启动数据库报错,需要进一步处理。
SQL> alter database open;
alter database open
*
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

做介质恢复,直到返回报告,恢复完成。
12、尝试open数据库。
SQL> alter database open resetlogs;
13、数据库启动成功。把原来temp表空间的数据文件加入到对应的temp表空间中。
14、对数据库进行各种常规检查,没有发现任何错误。
15、进行emp备份,全库备份完成,没有报错。将应用程序连接到数据库,进行应用层面的数据验证,一切正常,本次数据恢复工作完成。
阅读(93) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~