发布网友 发布时间:2022-04-22 04:57
共5个回答
懂视网 时间:2022-04-09 20:24
使用专业坏道硬盘镜像设备对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备份。全库备份完成,没有报错。将应用程序连接到数据库,进行应用层面的数据验证。
数据验证结束,数据库修复完成,数据恢复成功。
RAID重组和数据库数据的修复与验证
标签:数据库数据 windows manager 数据恢复 storage
热心网友 时间:2022-04-09 17:32
RAID5需要计算出原来的块大小和盘序还有校验循环方向才可以正确重组出数据,如果你对文件系统结构不熟悉的话 ,不建议你自己动手恢复,不过可以看我空间的文章了解下详细的知识也不错。RAID5没同时坏两块硬盘是可以 完全恢复数据。具体可以看我空间信息咨询QQ热心网友 时间:2022-04-09 18:50
您好,碰见这种情况很不幸运,只能求救专业数据恢复公司来处理热心网友 时间:2022-04-09 20:24
如果是RAID5 的话,首先要排除掉每一块成员盘的软硬故障(raid 5 支持一盘损坏),分析出陈列开始扇区号---硬盘盘序-条带大小--数据循环方向(左同步,左异步,右同步,右异步),然后用软件虚拟重组出来,建议你取下硬盘时对硬盘做一个数字顺序标记,这样可以便于以后数据恢复。热心网友 时间:2022-04-09 22:16
如果盘阵掉盘千万不要再做初始化操作。需要对各个盘进行分析确定分块大小及盘序,然后采用虚拟重组的方式,导出数据,具体操作时一般使用十六进制编辑器。