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

86次阅读

共计 2654 个字符,预计需要花费 7 分钟才能阅读完成。

服务器数据恢复环境:
IBM 某型号存储服务器;
16 块单盘容量 600G 的 FC 硬盘。

服务器故障:
指向 10 号和 13 号硬盘的指示灯显示为黄色;
存储映射到 redhat 上的卷挂载不上,业务中断。

存储服务器数据恢复过程:
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 号盘所有扇区的镜像。
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 文件夹及其所有文件的属组和权限。

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 备份。全库备份实现,没有报错。将应用程序连贯到数据库,进行利用层面的数据验证。

正文完
 0