【数据库数据恢复】SAP应用+Oracle数据库数据恢复案例

服务器数据恢复环境：

6块SAS硬盘中的5块硬盘组成一个RAID5的阵列，1块作为热备盘使用。
服务器故障：

RAID5中1块硬盘故障，热备盘激活开始同步数据，在同步数据过程中又有一块硬盘故障离线，导致RAID5瘫痪，上层LUN无法正常使用。
服务器故障检测和备份：

1、检测磁盘。初步判断是RAID阵列中某些磁盘掉线导致存储不可用。因此在接收到磁盘以后先对所有磁盘做物理检测，检测发现只有一块硬盘有物理故障。

2、备份数据。将所有磁盘都镜像成文件，备份过程中也没有发现其他磁盘物理故障。
服务器故障分析：

1、分析故障原因
因为IBM存储控制器对于磁盘的检测策略很严格，磁盘性能不稳定也会被IBM存储控制器判定为坏盘并踢出RAID组。因此检测出的故障磁盘有可能是读写不稳定，也有可能存在物理故障。而一旦RAID中掉线盘数超过这组RAID本身允许掉线盘的最大数量，那么这个RAID组将不可用，基于RAID组的LUN也将不可用，因此导致数据丢失。

2、分析RAID组结构
IBM存储的LUN都是基于RAID组的，因此需要先分析底层RAID组的信息，然后利用分析获取到的信息重构原RAID组。分析每一块数据盘，如果哪块盘的数据同其他数据盘不太一样，可以初步认定为HotSpare盘。分析其他数据盘，分析Oracle数据库页在每个磁盘中分布的情况，并根据数据分布的情况得出RAID组的条带大小，磁盘顺序及数据走向等RAID组的重要信息。

3、分析RAID组中的LUN信息
由于LUN是基于RAID组的，因此需要根据上述获取到的信息将RAID组虚拟重组出来，然后分析LUN在RAID组中的分配情况，以及LUN分配的数据块MAP。只需要将LUN的数据块分布MAP提取出来。然后针对这些信息编写相应的程序，对LUN的数据MAP做解析，然后根据数据MAP导出LUN的数据。

服务器数据恢复解决方案：

1、实施方案一
对恢复的包含Oracle数据库的LUN进行JFS2文件系统解析，并对文件系统不完整的部分进行人工修复。利用自主开发的JFS2文件系统解析工具解析恢复的LUN，然后恢复文件系统中所有的Oracle数据库文件，并检测Oracle数据库的文件是否完整。对检测有坏块的数据库文件所在磁盘进行扫描Oracle碎片操作，将扫描到的数据页进行组合，然后将有坏块的数据库文件通过人工的方式填补修复完整。在完成所有Oracle数据库文件的恢复之后，应用SAP还是无法正常使用。SAP应用的一些重要数据存放在损坏的存储中，缺失这些数据会导致SAP即使在数据库完整的情况下也无法正常使用，因此还需采用另外方案来恢复所有SAP的重要数据。

2、实施方案二
对恢复出来的所有LUN进行文件系统解析，将包含SAP的数据LUN进行文件系统的一致性检测。对文件系统不完整的部分进行人工修复，最后恢复所有SAP及SAP Test的数据。对SAP的数据进行检测，并对损坏的数据进行修复，确保恢复出来的SAP数据是完整的，这样才能保证SAP应用能够完整启动。利用恢复的SAP数据结合之前恢复出来的Oracle数据库，即可启动SAP及所有应用。
启动并修复Oracle数据及SAP应用：

1、启动Oracle数据库并修复
把恢复出来的数据库文件还原到已搭建好的环境中，并尝试启动数据库。在启动过程中由于数据库的一些临时文件校验不一致导致数据库启动失败。协调Oracle数据库工程师远程对数据库进行修复后，数据库正常启动，数据完整，然后尝试启动SAP。

2、启动SAP并修复
将恢复的SAP文件还原至已搭建好的环境中，并按照之前的启动脚本启动SAP，SAP启动正常，但SAP中用户权限及使用不正常，SAP表现为没有序列号。初步判断是SAP的注册文件没有恢复，重新检测恢复过程，排查可能出问题的部分。排查后发现是因为文件系统的损坏而导致某些文件没有恢复成功。重新修复文件系统，恢复这些数据。启动SAP正常，使用正常。

数据验证：

启动Oracle数据库，启动SAP，通过SAP客户端验证SAP中所有的数据，数据恢复完整，SAP能正常使用。