老菜鸟苦战oracle asm

作者:田逸(sery@163.com)from http://b.formyz.org/2011/0726/46.html

 
应用环境描述
一、硬件
1、 服务器:2台dell r610—16G内存、2颗6核xeon cpu、2个146G sas盘,做了raid1
2、 存储:dell MD3220 24个300G硬盘
3、 存储连接:6GB HBA卡,2个通道都连线了
二、软件
1、 系统:64位centos 5.5
2、 系统内核版本:Linux rac1 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
3、 asm软件:oracleasm-2.6.18-194.el5-2.0.5-1.el5.x86_64.rpm、oracleasm-support-2.1.7-1.el5.x86_64.rpm、oracleasmlib-2.0.4-1.el5.x86_64.rpm
4、 数据库软件:linux.x64_11gR2_database_1of2.zip、linux.x64_11gR2_database_2of2.zip
5、 集群软件:linux.x64_11gR2_grid.zip
 
故障描述
一、故障前的情况:
1、 集群实例正常运行
2、 asm能用asmcmd查看目录和文件
3、 数据库实例正常
4、 监听器正常
5、 客户端远程连接正常
6、 多路径访问正常
7、 /dev/oracleasm/disks目录的下的文件全部存在
二、故障的起因:
1、 打算模拟服务器失效
2、 直接重启两个服务器 init 6
三、故障现象:
1、 两个服务器的asm实例都没有启动成功
2、 两个服务器的oracle实例都没有启动成功
3、 Crs等进程启动几个,但基本上不能正常工作
4、 手动启动crs,失败
5、 以grid用户手动连接实例,强制启动,失败
 
故障基本原因判断
数据库数据文件、集群软件所需的ocr文件都存储在asm设定的共享存储中,由于集群软件(包括asm实例)启动失败而最终也导致数据库实例启动失败。
 
处理过程
一、定位故障点:
1、查看系统进程,发现ASM进程没有起来。但有少许grid相关的进程,如下图所示:

2、手动执行 /u01/app/grid/bin/crsctl start crs 失败
3、查看设备文件目录 /dev/mapper,发现共享存储的分区全部存在

[root@rac2 ~]# ll /dev/mapper/
total 0
crw------- 1 root root 10, 63 Jul 24 00:00 control
brw-rw---- 1 root disk 253, 0 Jul 24 00:01 mpath13
brw-rw---- 1 root disk 253, 10 Jul 24 00:01 mpath13p1
brw-rw---- 1 root disk 253, 11 Jul 24 00:01 mpath13p2
brw-rw---- 1 root disk 253, 12 Jul 24 00:01 mpath13p3
brw-rw---- 1 root disk 253, 13 Jul 24 00:01 mpath13p5
brw-rw---- 1 root disk 253, 14 Jul 24 00:01 mpath13p6
brw-rw---- 1 root disk 253, 15 Jul 24 00:01 mpath13p7
brw-rw---- 1 root disk 253, 16 Jul 24 00:01 mpath13p8
brw-rw---- 1 root disk 253, 1 Jul 24 00:01 mpath14
brw-rw---- 1 root disk 253, 3 Jul 24 00:01 mpath14p1
brw-rw---- 1 root disk 253, 4 Jul 24 00:01 mpath14p2
brw-rw---- 1 root disk 253, 5 Jul 24 00:01 mpath14p3
brw-rw---- 1 root disk 253, 6 Jul 24 00:01 mpath14p5
brw-rw---- 1 root disk 253, 7 Jul 24 00:01 mpath14p6
brw-rw---- 1 root disk 253, 8 Jul 24 00:01 mpath14p7
brw-rw---- 1 root disk 253, 9 Jul 24 00:01 mpath14p8
brw-rw---- 1 root disk 253, 2 Jul 24 00:01 mpath15

4、初步怀疑是asm磁盘组出故障了,于是执行 oracleasm listdisks,发现输出只有一行,可实际上是10多行的。

[root@rac2 ~]# oracleasm listdisks
DATA06

 
5、执行oracleasm scandisks扫描,再次查看输出磁盘,还是只有一个。查了网上的资料,也有这种情况,别人的经验是多执行几次asm磁盘扫描就出来了,但对我这个情况无效。
6、当我们初始化创建asm磁盘组时,使用命令 oracleasm createdisk OCR1 /dev/mapper/mpath14p1 执行成功后,将在目录/dev/oracleasm/disks目录生成OCR1这个文件,文件名就是asm的磁盘名;创建多少asm磁盘,就会有多少同名文件。进入目录/dev/oracleasm/disks,查看一下,只剩下一个块设备文件DATA06,其余的全部不见了。

[root@rac2 ~]# ll /dev/oracleasm/disks/
total 0
brw-rw---- 1 grid asmadmin 8, 22 Jul 24 00:01 DATA06

oracleasm listdisks 输出的结果完全一致,由此可知asm磁盘组与操作系统这个目录有直接的关联。这几者的关系可以如下图标识:
 

 
现在要做的事情是能不能恢复余下的磁盘文件。
 
二、处理方法
1、先上网搜索一下吧,搜出来不少,都是建议用dd清理磁盘,然后再用oracleasm createdisk 重新创建磁盘组。但我担心这样做,asm磁盘里面的数据会全部丢失,没敢这样尝试。
2、打电话问我原来的同事,他现在转行做dba了。他告诉我,看看是不是设备文件的权限问题,我到服务器上去查看,发现一个机器的/dev/mapper/mpath* 的属主是 root:disk,而另一个服务器相应的目录属主却是grid:oinstall。按照他的建议,我在文件/etc/rc.local写入了行“chown –R grid:oinstall”,然后重启系统,查看目录确实属主按我的意愿变成grid:root,但asm磁盘仍然不能识别,看来问题不在这里。
3、在多个qq群发送消息,有说权限问题的,也有建议oracleasm scandisk 的。还有的人认为oracleasm服务没有运行起来。还有的人说是裸设备权限问题,我可是没有使用裸设备啊,打开文件/etc/sysconfig/rawdevices,没有任何生效的文本行(全部被注释上了),这应诊了没有使用裸设备。
 
搞了好几天,没得进展。一天睡在床上,有想起这个问题,既然/dev/oracleasm/disks有DATA06这个文件,能不能手工创建一些呢(即丢失的那些文件),于是又爬起来。但当我手动执行touch /dev/oracleasm/disks/DATA08时,提示没有权限。看来,只能用mknod之类的命令才可以在这个目录创建文件。
 
念头一转,又想:既然DATA06这个文件存在,可能会在某些文件中有记录吧?执行grep DATA06 /etc -r 全路径搜索,还真搜到一个文件 /etc/blkid/blkid.tab,这个文件的如下:

[root@rac1 ~]# more /etc/blkid/blkid.tab
<device DEVNO="0x0807" TIME="1311517843" LABEL="/u011" UUID="0aa29b92-8132-4749-
b016-5190e1a7bcc6" TYPE="ext3" SEC_TYPE="ext2">/dev/sda7</device>
<device DEVNO="0x0806" TIME="1311517843" LABEL="/tmp1" UUID="e6370305-9868-4190-
a256-b9bc84c07b75" TYPE="ext3" SEC_TYPE="ext2">/dev/sda6</device>
<device DEVNO="0x0805" TIME="1311517843" LABEL="/usr1" UUID="d54e800b-b1c8-4d0f-
9095-955122dc5ff1" TYPE="ext3" SEC_TYPE="ext2">/dev/sda5</device>
<device DEVNO="0x0803" TIME="1311517843" LABEL="/var1" UUID="ee60d33f-0c2b-4e80-
93ff-f442c99f6dcf" TYPE="ext3" SEC_TYPE="ext2">/dev/sda3</device>
<device DEVNO="0x0802" TIME="1311517849" TYPE="swap" LABEL="SWAP-sda2">/dev/sda2
</device>
<device DEVNO="0x0801" TIME="1311517843" LABEL="/1" UUID="08e3c9b3-3cfe-403c-9cd
8-ff9e007602fd" TYPE="ext3" SEC_TYPE="ext2">/dev/sda1</device>
<device DEVNO="0x0000" TIME="1311517849" TYPE="swap">/u01/swapfile</device>
<device DEVNO="0xfd10" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/ma
pper/mpath14p8</device>
<device DEVNO="0xfd09" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/mapper/m
path15p8</device>
<device DEVNO="0xfd0e" TIME="1311441535" LABEL="DATA06" TYPE="oracleasm">/dev/ma
pper/mpath14p6</device>
<device DEVNO="0xfd0d" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/mapper/m
path14p5</device>
<device DEVNO="0xfd06" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/mapper/m
path15p5</device>
<device DEVNO="0xfd0c" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/mapper/m
path14p3</device>
<device DEVNO="0xfd05" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/mapper/m
path15p3</device>
<device DEVNO="0xfd0b" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/mapper/m
path14p2</device>
<device DEVNO="0xfd04" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/mapper/m
path15p2</device>
<device DEVNO="0xfd0a" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/mapp
er/mpath14p1</device>
<device DEVNO="0xfd03" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/mapp
er/mpath15p1</device>
<device DEVNO="0x0811" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/sdb1
</device>
<device DEVNO="0x0812" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/sdb2</de
vice>
<device DEVNO="0x0813" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/sdb3</de
vice>
<device DEVNO="0x0815" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/sdb5</de
vice>
<device DEVNO="0x0816" TIME="1311441535" LABEL="DATA06" TYPE="oracleasm">/dev/sd
b6</device>
<device DEVNO="0x0818" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/sd
b8</device>
<device DEVNO="0x0821" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/sdc1
</device>
<device DEVNO="0x0822" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/sdc2</de
vice>
<device DEVNO="0x0823" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/sdc3</de
vice>
<device DEVNO="0x0825" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/sdc5</de
vice>
<device DEVNO="0x0828" TIME="1311441535" LABEL="" TYPE="oracleasm">/dev/sdc8</de
vice>
<device DEVNO="0x0841" TIME="1311441536" LABEL="" TYPE="oracleasm">/dev/sde1
</device>
<device DEVNO="0x0842" TIME="1311441536" LABEL="" TYPE="oracleasm">/dev/sde2</de
vice>
<device DEVNO="0x0843" TIME="1311441536" LABEL="" TYPE="oracleasm">/dev/sde3</de
vice>
<device DEVNO="0x0845" TIME="1311441536" LABEL="" TYPE="oracleasm">/dev/sde5</de
vice>
<device DEVNO="0x0846" TIME="1311441536" LABEL="DATA06" TYPE="oracleasm">/dev/sd
e6</device>
<device DEVNO="0x0848" TIME="1311441536" LABEL="" TYPE="oracleasm">/dev/sd
e8</device>
<device DEVNO="0x0851" TIME="1311441536" LABEL="" TYPE="oracleasm">/dev/sdf1
</device>
<device DEVNO="0x0852" TIME="1311441536" LABEL="" TYPE="oracleasm">/dev/sdf2</de
vice>
<device DEVNO="0x0853" TIME="1311441536" LABEL="" TYPE="oracleasm">/dev/sdf3</de
vice>
<device DEVNO="0x0855" TIME="1311441536" LABEL="" TYPE="oracleasm">/dev/sdf5</de
vice>
<device DEVNO="0x0858" TIME="1311441536" LABEL="" TYPE="oracleasm">/dev/sdf8</de
vice>

从输出能看出一些端倪,凡是label为空的,就是asm磁盘丢失的。照这个思路,我手动在这个文件改了对应的3行,使其label=“DATA08”。DATA08是当时用oracleasm createdisk创建出来,预留下来的。因为没有数据存在这个DATA08磁盘,所以就是破坏了,也无关紧要。接着执行oracleasm scandisks ; 再 oracleasm listdisks 还是没有任何变化,看来这招也不灵。最后重启系统,看是否有效,还是一样。后来才知,/etc/blkid/blkid.tab文件的内容是运行blkid后从系统目录/dev下读入数据再自动生成的。
 
难道只得重新推到再来一次?不甘心啊!倒不是怕数据丢失,而是担心下次这个问题再次发生。
 
再准备推到重来之前,我再来试试创建一个asm磁盘。还是拿没有使用的/dev/mapper/mpath14p8分区来做,反正做坏了,也没什么影响。当执行oracleasm createdisk DATA08 /dev/mapper/mpath14p8,没有成功,其输出为:

Device "/dev/mapper/mpath14p8" is already labeled for ASM disk“”

这个输出给我很好的提示,它说明了asm 磁盘标签是存在的,但其值为空(它本来的值应该是DATA08)。于是我就思量,能不能强制把它由空值改成原来的值呢?
 
不知道怎么改oracle asm磁盘标签,不过这难不倒咱。打开文件 /etc/init.d/oracleasm瞧瞧,乖乖,找到了呢.看下面一段函数:

force_relabel_disk()
{
    OLD="$1"
    NEW="$2"
 
    echo -n "Renaming disk \"${OLD}\" to \"${NEW}\": "
    "${ORACLEASM}" renamedisk -f -v -l "${ORACLE_ASMMANAGER}" "${OLD}" \
        "$2" 1>>/var/log/oracleasm 2>&1
    if_fail "$?" "Unable to rename disk \"${OLD}\" see /var/log/oracleasm"
}

红色字体这行,就是强制性改asm磁盘标签的语法。迫不及待,马上执行 oracleasm renamedisk -f /dev/mapper/mpath14p8 DATA08 ,很顺利进行下去了。现在切换到目录/dev/oracleasm/disks,设备文件DATA08出现了,心里一阵狂写啊!在另一个主机上执行oracleasm scandisk ,接着执行oracleasm listdisks ,看见DATA08闪耀登场。由此可以预计,只要按以前的标签名,把对应的asm磁盘强制改名,就应该可以恢复。
 
先不急于把所有的asm磁盘标签恢复,从ocr所在的磁盘标签做起。本案的ocr用了两个asm 磁盘,其名称为OCR1、OCR2(幸亏以前安装rac的时候,做了屏幕录像),执行下面两条命令:

oracleasm renamedisk -f /dev/mapper/mpath14p1 OCR1
oracleasm renamedisk -f /dev/mapper/mpath15p1 OCR2

成功执行后,用 oracleasm scandisks扫描,检查目录/dev/oracleasm/disks,文件OCR1、ORC2都存在了;检查 oracleasm listdisks的输出,确实有OCR1和OCR2.
 
Ocr恢复了,可以试着启动crs.以root命令执行 crsctl start crs ,回车后,系统一阵沉默,上个厕所回来,执行完毕返回shell提示符下。赶紧ps auxww|grep –I asm查看进程,asm实例确实起来了.切换到grid用户,执行asmcd,顺利进入交互模式,ASMCMD>ls 输出为:

ASMCMD> ls
DGCRS/

注:DGCRS是由OCR1、OCR2两者合并而成。
再另一个服务器上,启动crs,asm实例正常运行起来了。
 
现在,可以放心的强制更改余下的asm标签,完毕后目录的文件日下:

[root@rac1 dev]# ll /dev/oracleasm/disks
total 0
brw-rw---- 1 grid oinstall   8, 18 Jul 26 17:05 DATA02
brw-rw---- 1 grid oinstall   8, 19 Jul 26 17:05 DATA03
brw-rw---- 1 grid oinstall   8, 21 Jul 26 17:05 DATA05
brw-rw---- 1 grid oinstall   8, 22 Jul 24 22:31 DATA06
brw-rw---- 1 grid oinstall   8, 24 Jul 26 17:05 DATA08
brw-rw---- 1 grid oinstall   8, 34 Jul 26 17:05 DATA12
brw-rw---- 1 grid oinstall   8, 35 Jul 26 17:05 DATA13
brw-rw---- 1 grid oinstall   8, 37 Jul 26 17:05 DATA15
brw-rw---- 1 grid oinstall 253, 14 Jul 24 22:41 DATA16
brw-rw---- 1 grid oinstall   8, 40 Jul 26 17:00 DATA18
brw-rw---- 1 grid oinstall   8, 17 Jul 26 17:05 OCR1
brw-rw---- 1 grid oinstall   8, 33 Jul 24 22:32 OCR2

确认无误后,联系相关人员告知要启动数据库了。再次检查ORACLE_SID、asm磁盘标签等,深呼吸一下,缓慢地输入/u01/app/grid/bin/srvctl start database -d DD4QIGOU 回车,起身离座喝口统一鲜橙多(估计有塑化剂)。估计数据库启得差不多了,回坐查看,oracle实例全部正常起来。不过有一点意外,就是服务器交换了各自的实例(rac1运行的实例是db4qigou_2、而rac2运行的实例是db4qigou_1);这不要紧,关闭各种的实例,在rac1上执行$srvctl start instance -d DB4QIGOU -i DB4QIGOU_1 -n rac1 ,rac2上执行srvctl start instance -d DB4QIGOU -i DB4QIGOU_2 -n rac2就扳过来了。
 
补充:oracle官方站点有建议修改 /etc/sysconfig/oracleasm文件的扫描顺序,但在本例无效。