ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 【RAC】存储阵列电源故障导致RAC数据库异常挂起

【RAC】存储阵列电源故障导致RAC数据库异常挂起

原创 Linux操作系统 作者:secooler 时间:2011-03-29 23:03:58 0 删除 编辑
将曾经经历过的一起RAC故障总结在此,希望引起大家的思考和总结。

1.故障现象
故障现象非常的明显,无论使用何种手段均无法启动RAC对应的服务。

在尝试启动数据库实例的过程中alert记录了如下信息。
Wed Feb  9 09:32:33 2011
This instance was first to mount
Wed Feb  9 09:32:33 2011
ORA-00202: control file: '+ORADATA/racdb/controlfile/current.256.668238016'
ORA-17503: ksfdopn:2 Failed to open file +ORADATA/racdb/controlfile/current.256.668238016
ORA-15001: diskgroup "ORADATA" does not exist or is not mounted
ORA-15077: could not locate ASM instance serving a required diskgroup
ORA-205 signalled during: ALTER DATABASE   MOUNT...
Wed Feb  9 09:35:13 2011
Reconfiguration started (old inc 2, new inc 4)
List of nodes:
 0 1
 Global Resource Directory frozen
 Communication channels reestablished
 Master broadcasted resource hash value bitmaps
 Non-local Process blocks cleaned out

这里提示磁盘组ORADATA未挂载成功,无法打开对应的控制文件。

2.故障分析
单纯从alert日志之中进行分析,很难直接定位是由于存储阵列的故障引发的这次数据库问题。
进一步追溯故障的根源。

1)查看裸设备的配置文件
cat /etc/udev/rules.d/60-raw.rules
# block devices with O_DIRECT.
#
# Enter raw device bindings here.
#
# An example would be:
#   ACTION=="add", KERNEL=="sda", RUN+="/bin/raw /dev/raw/raw1 %N"
# to bind /dev/raw/raw1 to /dev/sda, or
#   ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="1", RUN+="/bin/raw /dev/raw/raw2 %M %m"
# to bind /dev/raw/raw2 to the device with major 8, minor 1.

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/sdc2", 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"

2)查看操作系统中与之对应的设备信息
racdb1@racdb1 /dev$ ls -l | grep sd
brw-r-----  1 root disk   8,     0 2011-02-09 sda
brw-r-----  1 root disk   8,     1 02-09 09:26 sda1
brw-r-----  1 root disk   8,     2 02-09 09:26 sda2
brw-r-----  1 root disk   8,    16 2011-02-09 sdb
brw-r-----  1 root disk   8,    17 02-09 09:26 sdb1
brw-r-----  1 root disk   8,    18 02-09 09:26 sdb2
brw-r-----  1 root disk   8,    32 2011-02-09 sdc
brw-r-----  1 root disk   8,    33 02-09 09:26 sdc1
brw-r-----  1 root disk   8,    34 02-09 09:26 sdc2

故障的根本原因浮出水面,此时系统中并未识别到sdd相关设备!

这里的sdd相关设备便是磁盘组ORADATA需要的资源!

3)查看RAC所需磁盘信息
[root@racdb2 dev]# /etc/init.d/oracleasm listdisks
[root@racdb2 dev]#

返回结果为空,表明无可用存储。

3.故障处理
既然定位了故障出处,处理起来也便有的放矢。
最终确认了是由于存储阵列的电源故障引发的此次问题。

恢复故障后再次检查设备信息
racdb1@racdb1 /dev$ ls -l | grep sd
brw-r-----  1 root disk   8,     0 2011-02-09 sda
brw-r-----  1 root disk   8,     1 02-09 11:22 sda1
brw-r-----  1 root disk   8,     2 02-09 11:22 sda2
brw-r-----  1 root disk   8,    16 2011-02-09 sdb
brw-r-----  1 root disk   8,    17 02-09 11:22 sdb1
brw-r-----  1 root disk   8,    18 02-09 11:22 sdb2
brw-r-----  1 root disk   8,    32 2011-02-09 sdc
brw-r-----  1 root disk   8,    33 02-09 11:22 sdc1
brw-r-----  1 root disk   8,    34 02-09 11:22 sdc2
brw-r-----  1 root disk   8,    48 2011-02-09 sdd
brw-r-----  1 root disk   8,    49 02-09 11:22 sdd1
brw-r-----  1 root disk   8,    64 2011-02-09 sde
brw-r-----  1 root disk   8,    65 02-09 11:22 sde1
brw-r-----  1 root disk   8,    66 02-09 11:22 sde2
brw-r-----  1 root disk   8,    67 02-09 11:22 sde3

可见,存储上的设备已一一被识别。

racdb1@racdb1 /dev/raw$ ls -tlr
crw------- 1 oracle oinstall 162, 3 02-09 11:22 raw3
crw------- 1 oracle oinstall 162, 5 02-09 11:22 raw5
crw------- 1 oracle oinstall 162, 1 02-09 11:31 raw1
crw------- 1 oracle oinstall 162, 4 02-09 11:31 raw4
crw------- 1 oracle oinstall 162, 2 02-09 11:31 raw2

故障得到比较圆满的处理。

4.小结
RAC技术可以说是Oracle在高可用上的佳作和绝技,但是对于RAC的维护需要格外的细心,稍有不慎便会在细枝末节上出现纰漏,后果很严重!
谨以此文提醒RAC DBA朋友们:定期全面的健康检查不是例行公事,而是保障数据库高效稳定运行的前提!

Good luck.

secooler
11.03.29

-- The End --

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

请登录后发表评论 登录
全部评论
Oracle ACE 总监,阿里云MVP,北京大学理学硕士,恩墨学院创始人,教育专家,中国区 Cloudera 首位官方授权大数据讲师,金牌培训专家,BDA大数据联盟创始人,OCM联盟创始人,ACCUG创始人、ACOUG核心专家,Blogger。

注册时间:2008-03-16

  • 博文量
    797
  • 访问量
    8188483