【故障处理】多阵列挂接使设备名称混乱导致RAC无法启动问题

2019-12-28 05:17:12

今天遭遇RAC数据库服务器由于主机硬件问题导致重启，但服务器重启之后RAC数据库无法启动。
经分析，导致RAC任何一个节点都无法启动的原因是无法找到ocr导致crs无法正常提供服务。那因何ocr无故消失？

1.以下是采集到的相关故障日志
1）实例日志信息
Sun Aug 29 15:22:19 2010
Error: KGXGN aborts the instance (6)
Sun Aug 29 15:22:19 2010
Errors in file /oracle/app/oracle/admin/secrac/bdump/secrac2_lmon_21008.trc:
ORA-29702: error occurred in Cluster Group Service operation
LMON: terminating instance due to error 29702

2）ASM日志信息
ri Jul 9 13:05:10 2010
LMS 0: 5446 GCS shadows traversed, 0 replayed
Fri Jul 9 13:05:10 2010
Submitted all GCS remote-cache requests
Post SMON to start 1st pass IR
Fix write in gcs resources
Reconfiguration complete
Sun Aug 29 15:22:19 2010
Error: KGXGN aborts the instance (6)
Sun Aug 29 15:22:19 2010
Errors in file /oracle/app/oracle/admin/+ASM/bdump/+asm2_lmon_20702.trc:
ORA-29702: error occurred in Cluster Group Service operation
LMON: terminating instance due to error 29702

3）crs日志信息
cat /oracle/crs/oracle/product/10.2.0/crs/log/secrac2/alertsecrac2.log
2009-05-01 16:05:45.637
[crsd(5597)]CRS-1201:CRSD started on node secrac2.
2009-05-01 16:06:55.369
[cssd(6171)]CRS-1601:CSSD Reconfiguration complete. Active nodes are secrac1 secrac2 .
2010-08-29 15:21:37.028
[cssd(6171)]CRS-1606:CSSD Insufficient voting files available [0 of 1]. Details in /oracle/crs/oracle/product/10.2.0/crs/log/secrac2/cssd/ocssd.log.

4）ocssd.log日志信息内容
cat /oracle/crs/oracle/product/10.2.0/crs/log/secrac2/cssd/ocssd.log

[    CSSD]2010-08-29 15:21:37.118 [1126189376] >TRACE:   0x0x15a59c00 00 00 00                -                         ...
[    CSSD]2010-08-29 15:21:37.118 [1126189376] >TRACE:   clssscctx->nmctx->nmnode[002]->nodeData: dump of 0x0x15dfe510, len 61
[    CSSD]2010-08-29 15:21:37.118 [1126189376] >TRACE:   0x0x15dfe510 28 41 44 44 52 45 53 53 - 3d 28 50 52 4f 54 4f 43 (ADDRESS=(PROTOC
[    CSSD]2010-08-29 15:21:37.118 [1126189376] >TRACE:   0x0x15dfe520 4f 4c 3d 74 63 70 29 28 - 44 45 56 3d 31 38 29 28 L=tcp)(DEV=18)(
[    CSSD]2010-08-29 15:21:37.118 [1126189376] >TRACE:   0x0x15dfe530 48 4f 53 54 3d 31 30 2e - 31 30 2e 31 30 2e 32 29 HOST=10.10.10.8)
[    CSSD]2010-08-29 15:21:37.119 [1126189376] >TRACE:   0x0x15dfe540 28 50 4f 52 54 3d 32 31 - 31 34 38 29 29          (PORT=21148))
[    CSSD]2010-08-29 15:21:37.119 [1126189376] >TRACE:   clssscctx->nmctx->nmnode[002]->con: dump of 0x(nil), len 168
[    CSSD]--- DUMP GROCK STATE DB ---
[    CSSD]----------
[    CSSD] type 2, Id 3, Name = (crs_version)
[    CSSD] flags: 0x0
[    CSSD] grant: count=0, type 0, wait 0
[    CSSD] Member Count =2, master 0
[    CSSD]   . . . . .
[    CSSD]     memberNo =0, seq 0
[    CSSD]     flags = 0x0, granted 0

这些日志没有明显的说明故障原因。

2.继续挖掘问题原因
因为系统的crs无法启动，而且在关闭crs的过程中提示无法定位ocr文件。在检查裸设备信息的时候惊奇的发现ocr对应的raw1设备不翼而飞。
secrac1@secrac1 /home/oracle$ ls -l /dev/raw/*
crw------- 1 oracle oinstall 162, 2 08-29 10:14 /dev/raw/raw2
crw------- 1 oracle oinstall 162, 3 08-29 11:48 /dev/raw/raw3
crw------- 1 oracle oinstall 162, 4 08-29 10:14 /dev/raw/raw4
crw------- 1 oracle oinstall 162, 5 08-29 11:48 /dev/raw/raw5

3.问题原因浮出水面
在发现raw1不见之后，进而使用fdisk查看系统磁盘信息。此时，系统识别到的存储设备是从sdb开始编号的，原来的sda被其他设备抢占。因为Redhat 5.1操作系统下部署的RAC，裸设备是通过/etc/udev/rules.d/60-raw.rules文件进行指定的，因此sda的消失直接导致的结果就是raw1裸设备不可用，进而ocr数据无法访问，数据库当然无论从哪一个节点启动都无法成功。
# cat /etc/udev/rules.d/60-raw.rules
ACTION=="add", KERNEL=="/dev/sda1", RUN+="/bin/raw /dev/raw/raw1 %N"
ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="1", RUN+="/bin/raw /dev/raw/raw1 %M %m"
ACTION=="add", KERNEL=="/dev/sdb1", RUN+="/bin/raw /dev/raw/raw2 %N"
ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="17", RUN+="/bin/raw /dev/raw/raw2 %M %m"
ACTION=="add", KERNEL=="/dev/sdc1", RUN+="/bin/raw /dev/raw/raw3 %N"
ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="33", RUN+="/bin/raw /dev/raw/raw3 %M %m"
ACTION=="add", KERNEL=="/dev/sdd1", RUN+="/bin/raw /dev/raw/raw4 %N"
ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="49", RUN+="/bin/raw /dev/raw/raw4 %M %m"
ACTION=="add", KERNEL=="/dev/sde1", RUN+="/bin/raw /dev/raw/raw5 %N"
ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="34", RUN+="/bin/raw /dev/raw/raw5 %M %m"
KERNEL=="raw1", WNER="oracle", GROUP="oinstall", MODE="0600"
KERNEL=="raw2", WNER="oracle", GROUP="oinstall", MODE="0600"
KERNEL=="raw3", WNER="oracle", GROUP="oinstall", MODE="0600"
KERNEL=="raw4", WNER="oracle", GROUP="oinstall", MODE="0600"
KERNEL=="raw5", WNER="oracle", GROUP="oinstall", MODE="0600"

4.导致设备名称混乱的原因
与RAC数据库服务器挂载的光纤交换机上存在两套存储设备，就是那套与数据库无关的存储设备导致这起故障的发生。
设备名称的识别过程是在操作系统启动过程中自动完成的，这个应该与Redhat系统kernal有关。

5.小结
从这个案例中总结的的经验和教训：
1）有效的备份重于一切，有“备”无患，恢复只是时间的问题；
2）收到故障报警时需要时间介入排查；
3）一套有效可行的DRP会锦上添花。

Good luck.

secooler
10.08.30

-- The End --

分享好友

分享这个小栈给你的朋友们，一起进步吧。