内容发布更新时间 : 2024/12/26 20:36:31星期一 下面是文章的全部内容请认真阅读。

AIX系统存储故障后的Oracle 10g RAC恢复过程

客户数据库存储故障多日后终于修复了!一个月前客户的数据库

突然宕机，经检测为存储问题，这期间CRS和数据库一直未启动；直到今天，存储才修复，racdb1与racdb2服务器重启后，通知我说存储已经恢复正常，让我启动数据库，恢复加载，以下则是恢复经过；

环境:AIX 6.1小机，IBM存储，Oracle 10.2.0.4+asm数据库；

阶段一：

由于racdb1服务器重启时出了点故障，所以我准备从先启动的racdb2上启动数据库；

1) /etc/init.crs start启动crs，结果无任何反应；

2) ocrcheck检查ocr盘，报错；估计是硬盘识别有问题； 3) lsdev -Cc disk，检查硬盘状态，都正常；

4) lsvg，查看卷组情况，显示有rootvg，sysvg，datavg，indvg，经确认，除rootvg外其他vg都是数据库使用； 5) lsvg sysvg，报错，提示需要激活卷组； 6) varyonvg sysvg，成功；其他vg也同样操作；

7) 然后，再次lsvg sysvg，lsvg -p sysvg都正常；/etc/init.crs start启动crs和数据库都正常；至此，以为一切顺利，等racdb1起来后，再操作一遍即可； 阶段二：

登录racdb1，准备启动crs和数据库，步骤如下：

1) 由于有racdb2的经验，我首先检查磁盘和vg状态，发现磁盘

状态正常，vg需要激活，意料之中；于是varyonvg sysvg，报错：0516-013 varyonvg: The volume group cannot be varied on because…，并且与racdb2上不一样；

2) 为了能激活racdb1上的vg，尝试varyonvg -f ，exportvg/importvg，结果都失败；在这些尝试中却埋下了一个隐患；无赖之下，请教曾经配置过该服务器的工程师，经指点，是由于在激活vg时没有采用concurrent模式激活，所以单独激活racdb2上的vg没有问题，但是要激活共享的racdb1上vg则会有问题；

阶段三：

要想将racdb2上的已经激活的vg转成concurrent模式，只能（可能有直接转换的命令但不知道）是先将racdb2上vg先varyoffvg，再激活；登陆racdb2，进行如下操作：

1) 在racdb2上，shutdown immediate 数据库，shutdown ASM实例，再crsctl stop resources（还必须执行这步，不然varyoffvg报错），然后varyoffvg sysvg；

2) racdb2上，关闭所有vg后，以concurrent模式激活vg；varyonvg -c sysvg，-c选项为设置concurrent模式；结果报错：0516-1751 varyonvg；通过查找原因为需要启动AIX的高可用服务hacmp； 3) smit clstop字符界面，先停止aix cluster；然后smit clstart启动cluster，在字符界面中选择racdb1与racdb2一起启动，结果在启动失败；根据同事对hacmp的了解，也可单独启动，于是决

定在racdb2上单独启动，结果成功；

4) 现在马上以concurrent模式激活racdb2上vg；varyonvg -c sysvg，激活成功；lsvg sysvg检查vg状态，也已经正常；

阶段四：

在racdb2上成功激活所有vg后，现在要做的就是在racdb1上也以concurrent模式激活vg；登陆racdb1，操作如下：

1) 首先启动hacmp cluster服务；按照在racdb1上的启动方法，smit clstart，结果失败；仔细观察smit的输出日志，发现error描述indvg不存在；

2) 立刻检查racdb1上vg；lsvg，发现indvg确实不在列表中；经查发现是在先前尝试激活vg的过程中，执行了exportvg命令，该命令的含义为删除本节点上的vg信息；要想找回indvg，则需要知道indvg上至少一块pv的名称；在racdb2上执行lsvg -p indvg显示indvg上的pv；

3) importvg -y indvg vpath42，在racdb1上import找回indvg；（报错信息，由于indvg是concurrent模式，所以需要手动激活）； 4) smit clstart，启动hacmp；启动成功后，以concurrent模式激活racdb1上的所有vg；

阶段五：

racdb1和racdb2上的vg都以concurrent模式激活后，则可以启动数据库了；决定这次从racdb1上开始启动；

1) /etc/init.crs start，crs无反应；ocrcheck检查ocr盘正常；crsctl query css votingdisk检查表决盘也正常；crs无反应也未产生启动日志，也之前的vg未激活情况相似，根据经验有可能是ocr或votingdisk盘的权限或属组问题；

2) ls /dev/r*后发现，所有盘的属组都是root：system；根据oracle安装文档要求， #OCR盘

root:oinstall:0640

#voting disk盘

oracle:oinstall:0640

#ASM盘

oracle:dba:0660

按要求修改后，重新启动crs，全部正常；

3) racdb2上也有同样问题，依照racdb1上修改后也全部恢复正常；

至此，客户数据全部恢复正常！ 最后：

以root用户身份，运行smitty chvg命令，设置每个节点所拥有的卷组在系统启动时自动被激活。 # smitty chvg

Change a Volume Group

Type or select values in entry fields.

Press Enter AFTER making all desired changes. [Entry Fields]

* VOLUME GROUP name datavg

* Activate volume group AUTOMATICALLY yes + at system restart?

* A QUORUM of disks required to keep the volume no + group on-line ?

Convert this VG to Concurrent Capable?YES+ Change to big VG format? no + LTG Size in kbytes 128 + Set hotspare characteristics n +

Set synchronization characteristics of stale n + partitions 总结：

1.vg为RAC ASM使用时，需要以concurrent模式激活所有节点

的共享vg；

2.AIX下，要以concurrent模式激活vg时，必须先启动HACMP； 3.RAC环境下，激活所有vg后，最好检查一下将要加载到ASM

中的LV的权限；