设备文件引起的10gRAC-CRS服务故障
上一篇 / 下一篇 2008-05-29 11:50:24 / 个人分类：ORACLE
硬件环境
系统结构：2 Node Oracle 10gR2 RAC
Node OS：P570主机 AIX 5300平台
存储：DS4800
IBM CSC中心的一次计划性完全断电，(主机、存储的初始化)引起了测试环境上的RAC故障。在故障恢复中，通过排查问题，了解了不少以前从没关注的OCR相关知识点，收获颇丰。
问题描述：
主机重启后，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: # 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进行问题排查：
Check 1，检查OCR and voting disk设备文件
Node1的CRS服务启动失败，首先想到的是ocr和voting disk设备是否可用。
在各节点上检查设备文件，正常。两个节点的设备文件名一至，使用命令如下：
----检查OCR disk Status of Oracle Cluster Registry is as follows : Version : 2 Total space (kbytes) : 2096812 Used space (kbytes) : 3848 Available space (kbytes) : 2092964 ID : 685889688 Device/File Name : /dev/rhdisk22 Device/File integrity check succeeded Device/File not configured Cluster registry integrity check succeeded ----检查voting disk 0. 0 /dev/rhdisk23 located 1 votedisk(s). oracle@clostb2#] |
当然，/dev/rhdisk*只是数据库标识的disk file name,我们最好确认2个节点上识别的device是否为同一块hdisk。AIX平台上可以使用”lscfg –vl hdisk*”查看hdisk的serial number进行核对，如下：
root@clo1/>lscfg -vl hdisk32 hdisk32 U7879.001.DQD11JT-P1-C3-T1-W500507630300035A-L4000400100000000 IBM MPIO FC 2107 Manufacturer................IBM Machine Type and Model......2107900 Serial Number...............75474910001 EC Level....................2.27 Device Specific.(Z0)........10 Device Specific.(Z1)........0000 Device Specific.(Z2)........075 Device Specific.(Z3)........07605 Device Specific.(Z4)........08 Device Specific.(Z5)........00 root@clo1/> |
Check 2，检查OCR and voting disk设备文件的权限和属组
AIX平台上，在安装CRS服务之前，需要分别赋予OCR和voting disk设备盘以下属组和权限：
OCR disk device |
排查故障时，这个方面尤其是设备的读写权限很容易被忽略，我们的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用户修改故障节点的权限和属组后，重新启动CRS服务正常。
Check 3，检查OCR and voting disk设备的MPIO属性
在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平台上检查hdisk设备的属性使用”lsattr –El hdiskN”命令。
恢复故障节点中发现，在修改设备属组合权限修复了故障节点的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个节点的reserve_policy属性不一致，故障节点的设置reserve_policy为single_path，这显然是不对喽。错误信息如下：
root@clostb1/>lsattr -El hdisk22 PR_key_value none Persistant Reserve Key Value True cache_method fast_write Write Caching method False ieee_volname lun_id 0x0014000000000000 Logical Unit Number False max_transfer 0x100000 Maximum TRANSFER Size True prefetch_mult 1 Multiple of blocks to prefetch on read False pvid none Physical volume identifier False q_type simple Queuing Type False queue_depth 10 Queue Depth True raid_level 1 RAID Level False reassign_to 120 Reassign Timeout value True reserve_policy single_path Reserve Policy True rw_timeout 30 Read/Write Timeout value True scsi_id 0x190d00 SCSI ID False size 2048 Size in Mbytes False write_cache yes Write Caching enabled False root@clostb1/> |
修改reserve_policy为no_reserve，故障节点的CRS服务均恢复正常。命令如下：
“chdev -l hdisk22 -a reserve_policy=no_reserve”
注意：
检查voting disk及ASM使用的盘，均要设置reserve_policy=no_reserve
Check 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服务不正常的原因肯定有很多其他原因，我想，当我们遇到一个陌生的、不熟悉到问题时，理清思路，从和问题相关的方面开始着手，一点点屡，肯定会比毫无目的地到处看有效率的多！
导入论坛 引用链接 收藏 分享给好友 推荐到圈子 管理 举报
TAG:
