客户的一台DS5020光纤存储出现故障导致数据丢失,该存储使用了16块硬盘组成突袭磁盘阵列10号盘和13号盘掉线,6号盘警告,需要进行数据恢复。
<强>
突袭磁盘阵列故障情况:
通过IBM存储管理器将当前存储的完整日志状态备份下来,解析备份出来的存储日志获得了关于逻辑卷结构的部分信息。将客户服务器中所有磁盘按照固定顺序排序移出槽位进行测试发现该磁盘阵列中除6号盘聪明状态为“警告“外其他硬盘均正常。
<强>
磁盘阵列数据恢复过程:
工程师首先在windows环境下把突袭阵列中状态正常的硬盘标记为脱机,然后对所有磁盘记性全盘操作,在备份过程中发现6号硬盘速度异常缓慢,初步推测原因可能是因为该盘中不稳定扇区和坏道较多导致,于是更换专业针对坏道硬盘进行镜像的设备单独对6号硬盘进行镜像操作,同时将设备中遇到坏道响应,等待时间和跳过坏扇区数据进行调整。
经过镜像操作后,在windows平台下使用winhex镜像的磁盘已经全部镜像完成,查看winhex生成的日志,发现在IBM存储管理器/frombyte.com和硬盘聪明状态中均没有报错的1号盘也存在坏道,10号和13号盘均存在大量不规律的坏道分布,根据坏道列表定位到目标镜像文件分析发现该磁盘阵列中文件系统部分关键数据处于坏道区,于是转为通过6号硬盘的同条带xor手动修复。我们借助数据恢复软件将备份出来的突袭中的所有数据展开,对ext3文件系统的逆向以及日志文件进行整理分析从而分析出突袭磁盘阵列的盘序,raid块大小,raid的校验走向和校验方式等必要信息。
通过分析出来的raid信息虚拟重组突袭磁盘阵列并接卸ext3文件系统提取数据库文件。在对数据库文件的提取过程中出现报错,数据库报告imp - 0008错误,数据恢复工程师重新对raid结构进行分析,再一次进行dmp文件和dbf原始库文件进行提取,所有文件正常无报错。
<强>
数据库数据恢复流程
1。拷贝数据库文件到原数据库服务器,路径为/home/oracle/tmp/syntong。作为备份。在根目录下创建了一个oradata文件夹,并把备份的整个syntong文件夹拷贝到oradata目录下。然后更改oradata文件夹及其所有文件的属组和权限。
2。备份原数据库环境,包括ORACLE_HOME下产品文件夹下的相关文件。配置监听,使用原机中的splplus连接到数据库。尝试启动数据库到nomount状态。进行基本状态查询后,了解到环境和参数文件没有问题。尝试启动数据库到山状态,进行状态查询没有问题。启动数据库到开放状态。出现报错:
<代码> ora - 01122:数据库文件1失败验证检查/frombyte.com ora - 01110:数据文件1:'/oradata/syntong/system01.dbf ' ora - 01207:文件是最近比控制文件的控制文件
3。经过进一步的检测和分析,判断此故障为控制文件和数据文件信息不一致,这是一类因断电或突然关机等引起的常见故障。
4。对数据库文件进行逐个检测,检测到所有数据文件没有物理损毁。
5。在山状态下,对控制文件进行备份,改变数据库备份controlfile跟踪/备份/controlfile”;对备份的控制文件进行查看修改,取得其中的重建控制文件命令。把这些命令复制到一个新建脚本文件controlfile.sql中。
6。关闭数据库,删除/oradata/syntong/下的3个控制文件。启动数据库到nomount状态,执行controlfile。sql脚本。
<代码>完成启动nomount/frombyte.com 完成@controlfile.sql
7。重建控制文件完成后,直接启动数据库,报错,需要进一步处理。
<代码>完成;改变数据库开放; 改变数据库打开/frombyte.com * 误差在1号线: ora - 01113:文件1需要媒介恢复 ora - 01110:数据文件1:'/自由/甲骨文公司/oradata/oracle/system01.dbf”
然后执行恢复命令:
<代码>使用备份恢复数据库controlfile直到取消; 恢复联机重做日志:线程1组1 Seq 22阅读mem 0 Mem # 0犯错误:/自由/甲骨文公司/oradata/oracle/redo01.log …
做介质恢复,直到返回报告,恢复完成。
8。尝试开放数据库。
完成;改变数据库开放resetlogs;
9。数据库启动成功。把原来临时表空间的数据文件加入到对应的临时表空间中。
10。对数据库进行各种常规检查,没有任何错误。
11。进行emp备份。全库备份完成,没有报的错。将应用程序连接到数据库,进行应用层面的数据验证。
