设备文件引起的10gRAC-CRS服务故障
IBM CSC中心的一次计划性完全断电,(主机、存储的初始化)引起了测试环境上的RAC故障。在故障恢复中,通过排查问题,了解了不少以前从没关注的OCR相关知识点。
系统环境
系统结构:2节点Oracle 10gR2 RAC
主机系统:P570 AIX 5300
存储:DS4800
问题描述
主机重启后,RAC的1个节点故障,CRS服务不可用、尝试重启失败,且查看CRS服务的日志crsd.log没有任何记录更新,如下:
------------------------------------------------------------------------------------------------------
# crsctl start crs
Attempting to start CRS stack
The CRS stack will be started shortly
# ps -ef|grep d.bin
root 176436 127580 0 13:39:03 pts/3 0:00 grep d.bin
# crs_stat -t
CRS-0184: Cannot communicate with the CRS daemon.
# crsctl check crs
Failure 1 contacting CSS daemon
Cannot communicate with CRS
Cannot communicate with EVM
#
------------------------------------------------------------------------------------------------------
排查的过程中,发现的问题是层出不穷,简直是把AIX平台上CRS服务可能存在的故障完全遇到了一遍,让我觉得不总结都对不起一天的折腾。
OCR和voting disk是CRS服务的最重要的设备文件,所以遇到CRS服务有关的问题,我们可以从这两个设备文件相关的硬件设备hdisk进行问题排查。
解决过程
1. 检查OCR and voting disk设备文件
RAC节点的CRS服务启动失败,首先想到的是各节点上OCR和Voting disk设备是否可用、且一致。
检查RAC各节点的OCR和voting disk设备文件是否正常,命令如下:
- 检查OCR设备文件状态,root用户执行
#ocrcheck - 检查Voting Disk设备文件状态,oracle用户运行
#crsctl query css votedisk
当然,/dev/rhdisk*只是数据库 标识的disk file name,我们最好确认2个节点上识别的device是否为同一块hdisk。AIX平台上使用"lscfg –vl hdisk*”查看hdisk的sn号进行核对。
2. 检查OCR and voting disk设备文件的权限和属组
AIX平台上安装CRS服务之前,需要分别赋予OCR和voting disk设备盘以下属组和权限:
- OCR设备 chown root:dba /dev/rhdisk_OCR
chmod 660 /dev/rhdisk_OCR - Voting disk设备
chown oracle:dba /dev/rdisk_votedisk
chmod 660 /dev/rhdis_votedisk
排查故障时,设备的读写权限很容易被忽略,我遇到的问题原因之一就是由于OCR设备属组和读写权限不当导致CRS服务不正常。错误记录如下:
------------------------------------------------------------------------------------------------------
故障节点OCR设备
oracle@clostb1/oracle>ls -la /dev/rhdisk22
crw------- 1 root system 20, 23 May 28 11:44 /dev/rhdisk22
正常节点OCR设备
oracle@clostb2#]ls -la /dev/rhdisk22
crw-r----- 1 root dba 36, 23 May 28 14:57 /dev/rhdisk22
------------------------------------------------------------------------------------------------------
root用户修改故障节点OCR设备的权限和属组后,重新启动CRS服务,正常。
3. 检查OCR and voting disk设备的MPIO属性
恢复故障节点中发现,在修改设备属组合权限修复了故障节点的CRS服务后,另外一个节点的CRS服务又出现异常,如下:
-----------------------------------------------------------------------------------------------------
# crs_stat -t
CRS-0184: Cannot communicate with the CRS daemon.
#
# ocrcheck
PROT-602: Failed to retrieve data from the cluster registry
#
[oracle@clostb2#]crsctl query css votedisk
OCR initialization failed accessing OCR device: PROC-26: Error while accessing the physical storage Operating System error [Invalid argument] [22]
[oracle@clostb2#]
------------------------------------------------------------------------------------------------------
检查OCR设备文件发现,同一块盘在2个节点的MPIO属性不一致,故障节点OCR设备的reserve_policy属性设置为single_path,这是导致CRS服务故障的原因。
metlink上有OCR和voting disk设备MPIO属性设置的解释和命令,如下:
-----------------------------------------------------------------------------------------------------
To allow concurrent IO access to this disk device and prevent the device driver from locking the hdisks with a reservation on open, a no reservation flag must be set. Use the following chdev command to disable this reservation.
All MPIO-capable (ESS, DS8000, DS6000 devices):
- chdev -l hdiskn –a reserve_policy=no_reserve
- chdev -l hdiskm –a reserve_policy=no_reserve
For EMC (Symettrix &Clariion), HDS, IBM DS4000, and non-MPIO capable devices, perform. the following:
- chdev -l hdiskn –a reserve_lock=no
- chdev -l hdiskm –a reserve_lock=no
------------------------------------------------------------------------------------------------------
AIX平台上使用”lsattr –El hdiskN”命令检查hdisk设备的属性。修改reserve_policy为no_reserve,故障节点的CRS服务均恢复正常。命令如下:
#chdev -l hdisk22 -a reserve_policy=no_reserve
注意:检查voting disk及ASM使用的盘,均要设置reserve_policy=no_reserve。
4. 检查OCR设备的配置文件ocr.loc
ocr.loc文件是安装CRS服务时执行root.sh脚本过程中建立的,一般存放在/etc/oracle/路径下,主要记录crs服务启动时的ocr设备信息,内容如下:
------------------------------------------------------------------------------------------------------
# ls -trl /etc/oracle/ocr.loc
-rw-r--r-- 1 root dba 45 Apr 08 14:16 /etc/oracle/ocr.loc
# cat /etc/oracle/ocr.loc
ocrconfig_loc=/dev/rhdisk22
local_only=FALSE
#
------------------------------------------------------------------------------------------------------
如果ocr.loc设置的ocr盘与实际不符,或是该文件被清空等都回引起CRS服务故障,日志会记录无法访问OCR设备的错。我就遇到过该文件被清空,导致CRS服务不能启动的问题,折腾好久才发现。
引起CRS服务不正常的原因肯定有很多其他原因,遇到一个陌生的、不熟悉到问题时,理清思路,从和问题相关的方面着手、一点点找,肯定会比毫无目的地到处看有效率的多!
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26684/viewspace-622245/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/26684/viewspace-622245/