linux操作系统下oracle数据库数据恢复案例
最新动态来源：本站原创点击数：387更新时间：2024/9/27
服务器存储数据恢复环境&故障：
一台存储上有一组由16块FC硬盘组建了一组raid。存储前面板上的对应10号和13号硬盘的故障灯亮起，存储映射到redhat linux操作系统服务器上的卷挂载不上，业务中断。
服务器存储数据恢复过程：
1、通过存储的管理后台查看当前存储状态，管理后台报告逻辑卷状态失败。再查看物理磁盘状态，发现6号盘状态“警告”，10号和13号盘状态“失败”。在管理后台将当前存储的完整日志状态备份。解析日志获取到关于逻辑卷结构的部分信息。
2、将16块FC盘做好标记后从存储中移除，使用专用工具对16块FC盘进行初步检测， 发现16块盘均能正常识别。检测所有磁盘的SMART状态，发现6号盘的SMART状态为“警告”，和在存储管理后台中的报告一致。
3、将所有磁盘以只读方式进行扇区级别的全盘镜像。在镜像过程中发现6号磁盘的镜像速度很慢，结合之前的检测结果综合判断，6号盘应该存在大量损坏和不稳定的扇区。
4、使用专业设备对6号硬盘进行镜像，在镜像的同时观察镜像的速度和稳定性。经过观察发现6号盘的坏道并不多，但是存在大量读取响应时间长的不稳定扇区。调整6号盘的镜像策略后继续对6号盘进行镜像操作，同时观察镜像情况。6号盘镜像完成，但是之前的镜像策略会自动跳过一些不稳定扇区，所以现在的镜像是不完整的。调整镜像策略，继续镜像被跳过的扇区，直到6号盘所有扇区全部镜像完毕。
5、全部磁盘做完镜像后查看日志，发现在管理后台和SMART状态中均无报错的1号盘也存在坏道，10号和13号盘也存在大量不规则坏道。定位到目标镜像文件并经过分析，发现ext3文件系统的部分关键源数据信息已经被坏道破坏。只能利用6号盘通过同一条带进行xor，并根据文件系统上下文关系手动修复被损坏的文件系统。
6、将所有镜像文件全部展开。根据北亚企安数据恢复工程师对ext3文件系统的逆向研究和对日志文件的分析，获取到16块FC盘在存储中的盘序、RAID块大小、RAID的校验走向和方式等信息。根据上述获取到的信息虚拟重组RAID，RAID重组完成后进一步解析ext3文件系统。和用户后沟通提取出一些oracle的dmp文件并尝试进行恢复。
7、在使用dmp文件进行恢复的过程中，数据库报告imp-0008错误。仔细分析导入dmp文件的日志文件，发现恢复的dmp文件有问题。重新分析raid结构，并进一步确定ext3文件系统被破坏的程度，重新恢复出dmp文件和dbf原始库文件。将恢复出来的dmp文件移交给用户进行数据导入测试，测试过程一切顺利没有发现问题。对恢复出来的dbf原始库文件进行校验检测，所有文件均通过测试。
8、拷贝数据库文件到原数据库服务器作为备份，路径为/home/oracle/tmp/syntong。在根目录下创建了oradata文件夹，并把备份的syntong文件夹拷贝到oradata目录下。更改oradata文件夹及其所有文件的属组和权限。备份原数据库环境，包括ORACLE_HOME下product文件夹下的相关文件。
9、配置监听，使用原机中的splplus连接到数据库。尝试启动数据库到nomount状态，状态查询发现环境和参数文件正常。 尝试启动数据库到mount状态，状态查询也没有问题。启动数据库到open状态，出现报错。
10、经过检测和分析，北亚企安数据恢复工程师判断此故障原因是控制文件和数据文件信息不一致，这是一类由于异常断电或突然关机引起的常见故障。
11、逐个检测数据库文件，没有发现物理损毁。
12、在mount状态下，备份控制文件。查看修改备份的控制文件，取得其中的重建控制文件命令。把命令复制到一个新建脚本文件controlfile.sql中。
13、关闭数据库，删除/oradata/syntong/下的3个控制文件。 启动数据库到nomount状态，执行controlfile.sql脚本
14、重建控制文件完成后，直接启动数据库，仍然报错，需要进一步处理。
做介质恢复，直到返回报告。
15、尝试open数据库。
SQL>alter database open resetlogs;
16、数据库启动成功。把原来temp表空间的数据文件加入到对应的temp表空间中。
17、对数据库进行各种常规检查，没有任何错误。
18、进行emp备份。全库备份完成，没有报错。
19、将应用程序连接到数据库，在应用层面验证数据。
20、经过验证，用户方确认数据完整有效，认可数据恢复结果。