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、在数据库安装设计的时候，尽量不要增加不必要的环节，这样可以减少故障点

关注荣科云数据公众号：