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的权限；

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/16976507/viewspace-2130856/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/16976507/viewspace-2130856/