AIX 集群系统下的 Oracle RAC 故障处理方法

1、引言

AIX集群系统下的ORACLE RAC（Oracle Real Application Cluster）双机热备份有效地保障了企业重要的核心数据。但如果服务器在出现误操作意外断电时，会导致双机无法正常工作，这也将严重影响到企业核心数据的存储。

2、故障分析

本示例中出现的故障是由于数据库主服务器1号机出现硬件故障，由2号机接管一切服务的情况下，出现误操作使备机意外断电，致使两台数据库服务器全部瘫痪。

经过缜密的检查，发现2号主机OCR文件严重损坏。OCR文件记录节点成员的配置信息，如database、ASM、instance、listener、VIP等CRS资源的配置信息，可存储于裸设备或者群集文件系统。OCR文件的损坏直接导致ORACLE CRS的启动。CRS一般用来搭建Oracle的并行数据库，即RAC，但除了与RAC的接口之外，CRS还提供了一组高可用性的应用程序接口(API)，用来搭建一般应用程序的高可用集群，即一般我们常说的双机热备，比如使用CRS实现Oracle的双机热备。

3、处理过程

针对以上的故障分析，我们立即采取如下对策：

备份数据库

排除主机硬件故障

恢复OCR文件

1号主机：

该机硬件连续几天出现错误，并无规律宕机，IBM硬件工程师多次在现场进行数据搜集以及问题定位，最终确定为连接外接扩展单元的RIO卡存在可能的接触性问题。

之后在对该主机的RIO板卡，以及相关连线进行重新插拔连接后，慢启动模式硬件全面检查通过。

由于考虑到1号机作为HACMP的一个节点，可能对2号机现有的业务的影响，在修复当天关掉了该主机。

同时，IBM技术专家对该主机的问题进行全面会诊，并更换了RIO板卡，反复多次进行慢启动硬件全面检查，均无新的硬件报错，10日观察一天后，恢复了该主机上的业务。

2号主机：

该主机由于异常断电，可能造成了oracle RAC环境中数据镜像的ocr（oracle cluster registory）文件损坏，crs（cluster ready service）的12个服务全部不能启动。为了存储数据的安全性，首先对数据库进行全面备份。因为两套业务系统需要临时恢复，将2号机数据库服务恢复单机模式运行，但是运行于p561上的infamatic无法在单机模式下连接数据库。

cp cd/oracle/pro*/10*/crs*/cdata/adbcrs.bak拷贝相关文件

cpweek_.ocr week_.ocr.bak

./ocrdump ORADB2_OCRDUMP 查看OCR文件

ls*.dump 查看相关dump日志

cat*DUMP|grep WMST|wc –l执行dump中wc文件

./ocrcheck 执行ocr检查

/etc/init.crsstart 启动crs服务

./crs_stat 查看crs状态

oradb1:oracle:/home/oracle$]crs_stat-t

CRS-0184:Cannot communicate with the CRS daemon.

cd$ORACLE_HOME 进入ORACLE_HOME路径下

cd/oracle/network/admin/tnsnames.ora 查看tnsnames

connsys/oracle as sysdba

sqlplus sys/as sysdba

sqlplus 进入数据库并将相应RAC模式更改为单机模式

ps –ef|grepjava 查看java环境是否在启动状态

ps –ef|grepinfa 查看infamatic相关服务是否启动

在修复了1号机后，从2号机同步HACMP到1号机。然后进行数据库RAC环境的修复。

smittyhacmp，从2号机同步HACMP到1号机

ExtendedConfiguration

Synchronization

第二项改为yes→回车。

制定两套方案

方案1：参考国外相似案例，可清空oracle启动后在/tmp下生成的.oracle目录，重新启动RAC；

方案2：由于很可能在异常断电时造成oracle OCR文件的损坏，可以尝试修复OCR文件。

实施方案1

由于方案1风险小，实施快速，所以首先选择实施方案1。

实施后，发现属于1号主机的CRS服务无法online，手工启动也以失败告终。我们对照两台主机的/etc/inittab后发现，2号机是先起HACMP，然后才启动数据库相关的3个进程，而1号机刚好颠倒了顺序，遂立即修改1号机的inittab文件，保持与2号机启动的顺序一致，重启主机后，所有的CRS服务均可online。

$ORACLE_HOME/dbs/init.ora ORACLE数据库改为RAC模式

*.cluster_database= TRUE

*.cluster_database_instances= 2

*.undo_management=AUTO

启动CRS

1) 启动CRS

$ORA_CRS_HOME/bin/crs_start–all （oracle用户操作）

2) 两分钟后

启动命令执行完,等待两分钟后做如下检查

A. 确认CRS服务状态

$ORA_CRS_HOME/bin/crsctlcheck crs

B.手工确认如下4个进程是否启动

crsd

ocssd

oprocd

evmd

C.查看CRS资源状态

$ORA_CRS_HOME/bin/crs_stat-t

用$ORACLE_CRS这个环境变量

cd$ORA_CRS_HOME

tar cf/tmp/crs.tar crs/init crs/log css/init css/log evm/init evm/log srvm/log

1号机操作同上

在之后的测试中发现其中有3个CRS服务（adb.cs，db1.srv，db2.srv）不能自动online，target设置为offline，但每次都可以手工启动至正常状态。

[oradb1:oracle:/home/oracle$]crs_stat-t

ora....b1.instapplication ONLINE ONLINE oradb1

ora....b2.instapplication ONLINE ONLINE oradb2

ora.bietl.db application ONLINE ONLINE oradb2

ora.oradb.db application ONLINE ONLINE oradb2

ora....b1.instapplication ONLINE ONLINE oradb1

ora....b2.instapplication ONLINE ONLINE oradb2

ora.....adb.csapplication OFFLINE OFFLINE oradb2

ora....db1.srvapplication OFFLINE OFFLINE oradb1

ora....db2.srvapplication OFFLINE OFFLINE oradb2

ora....S1.lsnrapplication ONLINE ONLINE oradb1

ora.oradb1.gsdapplication ONLINE ONLINE oradb1

ora.oradb1.onsapplication ONLINE ONLINE oradb1

ora.oradb1.vipapplication ONLINE ONLINE oradb1

ora....S2.lsnrapplication ONLINE ONLINE oradb2

ora.oradb2.gsdapplication ONLINE ONLINE oradb2

ora.oradb2.onsapplication ONLINE ONLINE oradb2

ora.oradb2.vipapplication ONLINE ONLINE oradb2

在次日中午业务比较少的时段，尝试修复上述3个服务的启动状态。

导出上述3个服务的profile，修改其属性

TARGET=ONLINE

FAILURE_THRESHOLD=10

AUTO_START=always（之前为restore）

RESTART_ATTEMPTS=3（之前为0）

导入修改后的profile，3个服务均可以在主机启动后自动启动到online。

ora....b1.instapplication ONLINE ONLINE oradb1

ora....b2.instapplication ONLINE ONLINE oradb2

ora.bietl.db application ONLINE ONLINE oradb2

ora.oradb.db application ONLINE ONLINE oradb2

ora....b1.instapplication ONLINE ONLINE oradb1

ora....b2.instapplication ONLINE ONLINE oradb2

ora.....adb.csapplication ONLINE ONLINE oradb2

ora....db1.srvapplication ONLINE ONLINE oradb1

ora....db2.srvapplication ONLINE ONLINE oradb2

ora....S1.lsnrapplication ONLINE ONLINE oradb1

ora.oradb1.gsdapplication ONLINE ONLINE oradb1

ora.oradb1.onsapplication ONLINE ONLINE oradb1

ora.oradb1.vipapplication ONLINE ONLINE oradb1

ora....S2.lsnrapplication ONLINE ONLINE oradb2

ora.oradb2.gsdapplication ONLINE ONLINE oradb2

ora.oradb2.onsapplication ONLINE ONLINE oradb2

ora.oradb2.vipapplication ONLINE ONLINE oradb2

此时2号主机修复完成。

1，2号主机全部恢复到故障前的状态。

4、经验总结

采用清空oracle启动后在/tmp下生成的.oracle目录，重新启动RAC来恢复OCR文件，可以避免高风险造成的巨大损失。通过这次故障处理，我们可以对于以后的突发故障可以果断做出相应措施，也积累了很多宝贵经验。

由社区会员 wangweiww 分享

文档下载地址：

http://www.talkwithtrend.com/Document/detail/tid/97337