网站建设服务器

本案例详细介绍了服务器存储数据库的恢复过程，包括RAID重组和数据库数据修复验证。

背景介绍：

S5020光纤存储。存储16块FC硬盘，单盘容量600G。存储前面板上的10号和13号硬盘亮起故障灯，映射到redhat的卷无法挂载，业务崩溃。

开始工作：

通过存储管理器连接到存储以检查当前存储状态，然后检查物理磁盘状态。发现磁盘6报告“警告”，磁盘10和13报告“故障”。通过存储管理器，备份当前存储的完整日志状态，通过解析备份的存储日志，获得逻辑卷结构的一些信息。

图1:

十六个FC磁盘被标记，根据原始插槽号注册，然后从存储中移除。用FC磁盘镜像设备“R510 SUN3510”粗略测试了十六个FC磁盘后，发现十六个磁盘都能正常识别，并分别检测了十六个磁盘的SMART状态。因此，第六个磁盘的智能状态是“警告”，这与IBM storage manager中的报告一致。

在windows环境中，设备识别的FC磁盘在磁盘管理器中被标记为离线，这为原始磁盘提供了写保护功能。然后，使用软件在扇区级别镜像原始磁盘，原始磁盘中的所有物理扇区都被镜像到逻辑磁盘并保存为文件。在镜像的过程中，发现磁盘6的镜像速度非常慢。结合之前硬盘智能状态检测发现的问题，得出6号盘应该有大量损坏不稳定扇区，一般应用软件无法操作。

坏道镜像设备用于镜像6号硬盘。在镜像过程中，会同时观察镜像的速度和稳定性。发现6号硬盘坏道不多，但存在大量读响应时间长等不稳定扇区。因此调整了6号硬盘的拷贝策略，修改了跳过的扇区数量、响应等待时间等部分参数。继续镜像磁盘6。同时，观察其余磁盘的镜像。

镜像操作完成后，所有磁盘都已镜像。查看日志，发现1号磁盘也有坏磁道，存储管理器和硬盘智能状态都没有上报，10号磁盘和13号磁盘有大量不规则坏磁道，根据坏磁道列表，用软件定位目标镜像文件， 并且发现ext3文件系统的一些关键源数据信息已经被坏磁道破坏，只能等待6号盘通过同一磁带进行异或，根据文件系统上下文进行处理。

坏磁道镜像设备报告磁盘6的镜像已完成。但是，先前设置的最大化有效扇区和保护磁头的复制策略会自动跳过一些不稳定的扇区，因此当前镜像是不完整的，因此调整复制策略以继续镜像跳过的扇区，并且磁盘6的所有扇区都被完全镜像。

获取所有硬盘的物理扇区镜像，并通过平台下的软件展开所有镜像文件。根据我们对ext3文件系统和日志文件的逆向分析，得到了存储中16个FC磁盘的信息，RAID的块大小，RAID的校验方向和方式等等。于是我们尝试通过软件虚拟重组RAID，在RAID搭建完成后进一步分析ext3文件系统，通过与用户沟通提取oracle的一些dmp文件，用户尝试恢复。

在dmp恢复过程中，数据库报告为imp-0008错误。通过仔细分析导入的dmp文件的日志文件，发现恢复的dmp文件存在问题，导致dmp数据导入失败。立即重新分析raid结构，进一步确定ext3文件系统的破坏程度。经过几个小时的工作，恢复了dmp文件和原来的dbf库文件，将恢复后的dmp文件交给用户进行数据导入测试。结果测试中没有发现问题，说明这次数据恢复是成功的。然后，对恢复的dbf原始库文件进行检查和测试，所有文件都可以通过测试。

数据库恢复过程

1.将数据库文件复制到原来的数据库服务器上，路径是/home/oracle/tmp/syntong。

作为备份。在根目录中创建了一个oradata文件夹，并将整个syntong文件夹复制到oradata目录中。然后更改oradata文件夹及其所有文件的成员资格和权限。

2.备份原始数据库环境，包括ORACLE_HOME下的产品文件夹下的相关文件。在原始机器中使用splplus配置监控并连接到数据库。尝试将数据库启动到nomount状态。基本状态查询后，知道环境和参数文件没有问题。尝试启动数据库到mount状态，状态查询没有问题。将数据库启动到打开状态。出现错误：

图2:

3.经进一步检测分析，判断为控制文件和数据文件信息不一致，是停电或突然停机导致的常见故障。

4.逐个检查数据库文件，所有数据文件都没有物理损坏。

5.在挂载状态下，备份控制文件，将数据库备份控制文件修改为\ \ \ '/backup/control file \ \ '查看和修改备份的控制文件，并获取重建控制文件的命令。将这些命令复制到新的脚本文件controlfile.sql中。

6.关闭数据库并删除/oradata/syntong/下的三个控制文件。将数据库启动到nomount状态，并执行controlfile.sql脚本。

图3:

7.控制文件重建完成后，直接启动数据库，报错，需要进一步处理。

图4:

然后执行恢复命令：

图5:

执行介质恢复，直到报告返回且恢复完成。

8.尝试打开数据库。

SQL alter database open resetlogs

9.数据库成功启动。将原始临时表空间的数据文件添加到相应的临时表空间中。

10.对数据库执行各种常规检查，没有任何错误。

进行emp备份。整个数据库的备份已经完成，没有报告任何错误。将应用程序连接到数据库，以便在应用程序级别进行数据验证。

数据验证完成，数据库修复完成，数据恢复成功。

更多关于云服务器，域名注册，虚拟主机的问题，请访问西部数码代理官网：www.chenqinet.cn。