Linux分区信息丢失导致的asm无法启动问题

编辑手记

今天给大家介绍的这个案例是相对早期的一个案例,那个时候做集成项目大部分是分工明确的,通常是客户或业务人员要求容量空间,系统工程师分配对应大小的lun给系统,数据库工程师再去具体的按照数据库的安装要求分配空间。比如,系统工程师给系统划分了1个TB的磁盘,挂载后为sdb,数据库工程师再根据RAC的要求,划分vote盘、数据盘和归档盘等等,这就会用到Linux的分区,我们今天要说的案例正是分区信息丢失导致的。所以,我们还是建议大家再实施项目的时候,按照RAC的安装要求,划分对应的裸盘,去掉分区这一个环节,这样也会减少一个故障点。当然,也希望这个案例能够帮助到遇到类似问题的同行。

问题描述

客户有一套Linux上安装的Oracle10g RAC,ocr和vote放在ocfs共享文件系统,数据文件放置在ASM磁盘组里。这套系统运行两年多,主机从未重启过,有一天节点1因硬件故障宕机,修复后重新启动,发现ASM磁盘组无法挂载。

分析过程

发现ASM无法挂载,我们尝试手工挂载盘组,报错如下:

由于节点一异常,我们在节点2查看asm磁盘情况

可见使用了asmlib,从实例中查不到底层的磁盘信息,用以下命令检查卷标对应的磁盘信息

find /dev -type b -exec '/etc/init.d/oracleasm''querydisk' '{}' ';' 2>/dev/null | grep "is marked an ASM disk"

节点2显示如下

而节点1上所有sdb分区对应的设备文件都不见了

使用fdisk -l检查各磁盘分区,发现两个节点都没有sdb5-9的信息

根据现有分区状态判断,sdb5-9应该属于逻辑分区,但分区信息丢失。单独检查sdb的分区信息

fdisk /dev/sdb

看起来分区信息损坏了。由于是共享盘,两节点分区信息是一致的,那么可以认为一旦节点2也发生主机重启,其sdb分区设备文件将无法生成,ASM磁盘组也将无法挂载,数据库就彻底完了。之所以节点2现在还能正常工作,是因为分区设备文件还在。如何找回丢失的分区信息呢?好在节点2没有重启,在内存里还保留这个信息,解决问题的关键就在于如何找到这些信息,并重写sdb的磁盘分区表。

Linux下 /proc/partitions里存放着内存里的分区表信息,节点1的信息已经没法参考了,查看节点2的信息

这里记载了每个分区的使用blocks,也就是分区大小,blocks的单位是KB,如果想换算成分区的cylinder容量信息,还要参考换算关系

记算公式如下:

(end - start)* (16065*512)= blocks*1024

sdb5是第一个逻辑分区,起始位置(start)是251(扩展分区的起始位置),结束位置(end)应为

sdb6是第二个逻辑分区,起始位置是12701(12700+ 1),结束位置为

sdb7是第三个逻辑分区,起始位置是25151,结束位置为

sdb8是第四个逻辑分区,起始位置是37601,结束位置为

sdb9是第五个逻辑分区,起始位置是67001,结束位置为

按照以上计算,使用fdisk /dev/sdb重新划分sdb的逻辑分区,并最终使用“w”保存分区信息,重写后信息如下:

然后将节点1重启,重启后节点1恢复正常,至此,这个问题就算彻底解决了!

思考一下

结合这个案例,我们总结以下两点供大家参考

1、在RAC环境下进行硬件升级、维修等操作时,一定要保证一个节点存活,滚动操作,这样可以最大限度的减少对业务的损失,同时,也能够为解决问题提供一个参考

2、在数据库安装设计的时候,尽量不要增加不必要的环节,这样可以减少故障点

关注荣科云数据公众号:

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180321G0JG3P00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券