HP-EVA4400故障导致的oracle数据库丢失的恢复过程一、故障描述二、备份数据三、故障分析及恢复过程四、数据验证五、移交数据日后数据安全建议

整个eva存储结构是由一台eva4400控制器，三台eva4400扩展柜和28块fc 300g硬盘构成的。由于两块磁盘掉线导致存储某些lun不可用，某些lun丢失。由于eva4400是因为某些磁盘掉线，从而导致整个存储不可用。因此接收到磁盘以后北亚工程师先对所有磁盘做物理检测，检测完后发现没有物理故障。接着使用坏道检测工具检测磁盘坏道，发现也没有坏道。磁盘坏道检测日志如下：

图一：

考虑到数据的安全性以及可还原性，在做数据恢复之前需要对所有源数据做备份，以防万一操作不当导致数据无法再次恢复。使用winhex将所有磁盘都镜像成文件，源磁盘的内容数量多，在做数据备份的时候要花费很长时间。备份完部分数据如下：

图二：

由于前两个步骤并没有检测到磁盘有物理故障或者是坏道，由此推断可能是由于某些磁盘读写不稳定导致故障发生。因为eva控制器检查磁盘的策略很严格，一旦某些磁盘性能不稳定，eva控制器就认为是坏盘，就将认为是坏盘的磁盘踢出磁盘组。而一旦某个lun的同一个条带中掉线的盘到达极限，那么这个lun将不可用。即如果eva中所有的lun都包含这些掉线的盘，所有lun都会受影响。掉线两块盘导致整个存储的lun都不可用的情况就很正常了。而目前的情况是现存8个lun，损坏7个lun，丢失6个lun。需要恢复所有lun的数据。

hp-eva的lun都是以raid条目的形式存储数据的，eva将每个磁盘的不同块组成一个raid条目，raid条目的类型可以有很多种。我们需要分析出组成lun的raid条目类型，以及这个raid条目是由哪些盘的哪些块组成。这些信息都存放在lun_map中，每个lun都有一份lun_map。eva将lun_map分别存放在不同的磁盘中，使用一个索引来指定其位置。因此去每个磁盘中找这个指向lun_map的索引就可以找到现存lun的信息了。

虽然磁盘中记录了指向lun_map的索引，但是它只记录现存的lun，丢失的lun是不会记录索引的。由于eva中删除一个lun只会清除这个lun的索引，而不会清除这个lun的lun_map。这时需要扫描所有磁盘找到所有符合lun_map的数据块，然后排除掉现有的lun_map，剩下的lun_map也不一定全是删除的，也有一些是以前旧的，但此时是无法在lun_map中筛选了，只能通过程序将所有lun_map的数据都恢复出来，人工的去核对哪些lun是删除的。

在前面的故障分析中说了，虽然磁盘没有明显的物理故障，也没有磁盘坏道。但还是会因为性能的原因从eva磁盘组中脱离。而这些脱离的磁盘中都存放的是一些旧的数据，因此在生成数据的时候需要将这些磁盘都排除掉。但是如何判断哪些磁盘是掉线的呢？由于lun的raid结构大多都是raid5，只需要将一个lun的raid条目通过raid5的校验算法算出校验值，再和原有的校验值做比较就可以判断这个条目中是否有掉线盘。而将一个lun的所有lun_map都校验一遍就可以知道这个lun中哪些raid条目中有掉线盘。而这些raid条目中都存在的那个盘就一定是掉线盘。排除掉线盘，然后根据lun_map恢复所有lun的数据即可。

上述的故障分析以及解决思路最终都需要使用编程来实现。编写扫描lun_map的程序scan_map.exe，扫描全部lun_map，结合人工分析得出最精确的lun_map。编写检测raid条目的程序chk_raid.exe，检测所有lun中掉线的磁盘，结合人工分析排除掉线的磁盘。编写lun数据恢复程序lun_recovery.exe，结合lun_map恢复所有lun数据。

根据编写好的程序去实现不同的功能，最后使用lun_recovery.exe结合lun_map恢复所有lun的数据。然后人工核对每个lun，确认是否和甲方工程师描述的一致。部分lun的数据恢复如下：

图三：

根据甲方工程师描述所有lun的数据可以分成两大部份，一部份是vmware的虚拟机，一部分是hp-ux上的裸设备，裸设备里存放的是oracle的dbf数据库。由于我们恢复的是lun，无法看到里面的文件，因此需要将这些lun同过人工的核对哪些lun是存放vmware的数据，哪些是hp-ux的裸设备。然后将lun挂载到不同的验证环境中验证恢复的数据是否完整。

在一台dell的服务器上安装了esxi5.5虚拟主机环境，然后通过iscsi的方式将恢复的lun挂载到虚拟主机上。但是在vmware vsphere client 上扫描vmfs卷，没有发现。后来发现客户的虚拟主机是exsi3.5的版本。可能因为版本的原因无法直接扫描到vmfs卷，于是换一种验证方式。将所有符合vmware虚拟机的lun里面的虚拟机文件都生成出来，然后通过nfs共享的方式挂载到虚拟主机上，然后将虚拟机一个一个的添加到清单。恢复的部分虚拟机文件如下：

图四：

通过nfs将所有虚拟机都添加到虚拟主机以后，将所有虚拟机都加电开机，发现都能启动系统。由于没有开机密码无法确认虚拟机里面的文件是否完整。后来甲方安排工程师通过远程到我们的服务器，将所有虚拟机都开机进入系统，验证虚拟机里面的数据都没问题。虚拟机的所有数据都恢复成功。部分虚拟机开机如下：

图五：

为了裸设备恢复测试和后期的数据验证工作，需要先搭建好oracle 环境。

根据甲方工程师提供的环境信息为hp小机itanium架构，我公司hp小机为rx2660(itanium 2), 是同架构的兼容版本。于是计划在此机器上安装 oracle 单实例软件。

操作系统：hp-ux b.11.31

数据库：oracle 10.2.0.1.0 enterprise edition - 64bit for hpux

以下是安装环境的简单步骤介绍：

uname -all

hp-ux byhpux1 b.11.31 u ia64 1447541358 unlimited-user license

本机为ia64架构，操作系统为 hp-ux ，版本为 b.11.31。

然后检查各部分存储空间信息，保证空间足够。

根据安装说明“b19068.pdf”，检查 oracle10g 所需的补丁包。

检测：

swlist-l bundle |grep "gold"

swlist-l patch |grep phne_31097

如果没有检测到的，需要到官方网站下载并安装。 安装补丁包：

swinstall -s /patchcd/goldqpk11i -x autoreboot=true -x patch_match_target=true

groupadd dba

useradd -g dba -d /home/oracle oracle

passwd oracle

创建目录：

mkdir –p/opt/oracle/product/10.2/oracledb

chown -r oracle:dba/opt/oracle/frombyte.com

修改权限：

chown oracle:dba/usr/oracle_inst/database/

chmod 755/usr/oracle_inst/database/

vi /home/oracle/.profile

oracle的安装要求起图形界面，所以要先测试图像界面能够正常启动。

exoprt display=192.168.0.1.0:0

$./runinstaller

图像界面起来之后的安装就比较简单了，这里只安装软件，不安装实例。

su - oracle

$sqlplus / as syssdba

由于有部分lun是裸设备，而我们恢复的lun都是以文件的形式存在。因此需要将文件形式的lun挂载到hp-ux上。在hp-ux服务器上安装iscsi initiator，安装步骤如下：

检测软件包是否完整

swlist -d @ /tmp/b.11.31.03d_iscsi-00_b.11.31.03d_hp-ux_b.11.31_ia_pa.depot

安装软件包

swinstall -x autoreboot=true -s /tmp/b.11.31.03d_iscsi-00_b.11.31.03d_hp-ux_b.11.31_ia_pa.depot iscsi-00

将iscsi的可执行文件添加到path

path=$path:/opt/iscsi/bin/frombyte.com

检测iscsi是否安装成功

iscsiutil -l

配置iscsi的启动器名称

iscsituil /dev/iscsi -i -n iqn.2014-10-15:lun

配置挂载目标iscsi设备

iscsiutil -a -i 10.10.1.9

删除目标iscsi设备

iscsiutil -d -i 10.10.1.9

验证目标iscsi是否挂载成功

iscsiutil -pd

发现目标target设备

/usr/sbin/ioscan -h 255

为目标创建设备文件

/usr/sbin/insf -h 255

创建vg节点

mkdir /dev/vgscope/frombyte.com

创建vg设备文件名

mknod /dev/vgscope/group c 64 0x030000

查看pv是否正常

pvdisplay -l /dev/dsk/c2t0d0/frombyte.com

将pv导入vg中

vgimport -v /dev/vgscope /dev/dsk/c2t0d0

激活vg信息

vgchange -a y vgscope

查看vg信息

vgdisplay -v vgscope

图六：

由于是在新的环境上重建的vg，然后再将pv导入到新建的vg中。因此lv的名称全部都改变了，需要手动的去将lv的名称都改成和以前一下的。

图七：

因为原来数据库实例是有2个，并且是使用的裸设备存储。所以在创建数据库实例时，要按按照原来配置和命名。

文件系统层面，在同时协助下，挂载了所有lv,并修改权限。

图八：

安装数据库实例，根据原始配置，在客户dba协助下，安装并识别到所有裸设备文件。

然后调整配置参数，检测数据库存储状态，为启动数据库做准备。

首先切换到实例 scope（最重要）。,启动数据库。

sql>startup mount;

sql>select file#,error from v$recover_file; --查损坏的文件.

没有损坏的文件。

sql>alter database open;

启动没有报错，但是缓慢，之后查询了用户，随机查询了一个用户的两张表，数据结果集返回正常。然后连接突然中断，重新连接，查看状态为数据库关闭。再启动数据库，还是启动不了，会强制关闭。

经过初步检测和常规恢复库状态，不能修复此问题。

验证 njyy 数据库

将环境变量切换到另一个数据库njyy，open数据库时报错内存不足错误,不能开启数据库。经初步检测检测，数据文件没有损坏。

sql>select file#,error from v$recover_file;

error 4030 detected in background process

故障修复

对于scope数据库，根据上面的操作和故障现象，初步判断是undo表空间或者日志方面有问题。对数据文件做完整性和一致性检测，结果只有一个undo01.dbf文件损坏。确定是undo表空间损坏。通过命令删除掉损坏的undo表空间，又在原来位置重建。

检测其他部分文件，没有发现问题。重新启动数据库，正常启动，做查询数据，正常，做了完整性检测，正常。

接着做imp数据库全库导出，经过3个多小时正常导出全库数据库。

对于 njyy数据库，检测到是内存空间设置不对，经过命令调整，数据库恢复正常，能正常启动，正常使用。

最后做imp数据库全库导出，经过4个多小时正常导出全库数据库。

具体验证

在完成初步验证之后，甲方要求其dba和业务人员通过远程做数据库进一步具体验证。配合做了验证环境和各个数据库的验证。

最终验证数据库为完全恢复，没有问题。

在验证数据之后，做数据迁移。考虑到数据库的容量和恢复时间。选择用expdp来做全库数据的导出。因为expdp的效率比exp的高些。

编写好导出脚本，并在测试环境下测试没有问题后，先对scope数据库进行导出。导出开始后24分钟时，开始报错：

ora-39171: job is experiencing a resumable wait.

ora-01654: unable to extend index system.sys_mtable_00003a964_ind_1 by 8 in tablespace system

经过查找原因，得出是因为system表空间已满造成的。用expdp导出时会向system表空间里的system.sys_mtable_00003a964_ind_1表里加入导出记录数据.当导出大量数据时，此表的数据量就会增大，当达到system表空间的总容量时，就会报错。这里分析，表空间一般是会自动增加容量的，那样就不应该报错。最后查询出，system表空间是放在裸设备上的，容量为1g，且不可以增大。所以，就不能使用expdp工具做导出。 只能使用exp工具导出，虽然会慢一点，但是不会有system表空间不足的问题。

最后通过exp对scope做全库导出，经过6个多小时成功备份完成。备份文件达 172g。

对njyy数据库，做imp导出，经过7个多小时正常导出全库数据库，备份文件达140g.接着对数据库备份文件做了本地备份，作为安全冷备份。

验证所有数据没有问题后，将vmware虚拟机文件和oracle dump文件拷贝至一块2tb的希捷硬盘中。然后再将恢复出来的lun数据拷贝至两块3tb的单盘中。来到甲方现场后先将vmware虚拟机文件和oracle dump文件交给甲方后，甲方开始验证dump文件和vmware虚拟机文件。

由于甲方要求将所有lun数据恢复到原环境中，因此需要重新配置hp-eva4400，重新创建和以前一样大小的lun。然后通过winhex工具将恢复的lun数据全部镜像到eva新建的lun中。由于甲方的hp-eva4400的控制器存在一些问题导致调试了很久才重置hp-eva4400。镜像完所有lun数据后，甲方安排oracle数据库工程师验证恢复的oracle是否正常。检测后发现有两个dbf文件丢失导致oracle服务启动失败，分析故障原因后发现，因为这两个丢失的dbf在eva故障之前是以文件的方式存在，后来在恢复的时候，将其恢复到lv里面去了。而甲方工程师在恢复lv的时候并没有重建vg而是按照以前的vg_map恢复的所有lv。因此才会出现这个问题，解决办法，重新创建两个lv，然后从底层lun中将这两个文件取出，将其dd到新创建的lv中。再次启动oracle服务，启动正常，问题解决。

由于故障发生后保存现场环境良好，没有做相关危险的操作，对后期的数据恢复有很大的帮助。整个数据恢复过程中虽然遇到好多技术瓶颈，但也都一一解决。最终在预期的时间内完成整个数据恢复，恢复的数据甲方也相当满意。