ASM磁盘容量改变的故障处理

某个数据库环境中的ASM磁盘，由于历史原因，全部配置为没有RAID信息的JBOD模式。今天在做产品升级，由于软件需要，需要将原来加入到ASM中每个JBOD的磁盘配置为RAID0。配置过程采用了rolling up的方式，每次对一个diskgroup中的一个failgroup的磁盘配置RAID。 大体步骤为，以磁盘组ssddg的failgroup1为例：

1、在ASM中操作，将failgroup1的磁盘全部offline；

2、在OS层将这些磁盘卸载；

3、配置failgroup1的磁盘为raid0；

4、在OS层将这些磁盘加载；

5、在ASM中操作，将failgroup1的磁盘全部online。

有自信去做这件事是考虑到磁盘的数据不会受到影响，但是没有考虑到元数据。于是遇到下面的问题：

所有节点通过存储软件正常加载上来已经做成RAID0的磁盘。然而在asm磁盘组中要把这些盘online上来时报了下面这个错误：

初步一看，以为是自己操作的疏漏，共享磁盘在另一个RAC节点没有加载，才会报“磁盘不是集群范围可见”的错误；但检查了/dev下的路径以及通过dd命令确认可读写以后，可以确认这些盘都正常加载了，在OS层是集群可见的。

下一步，只能去asm的alert日志看看是否有更具体的报错信息。在alert日志的最后部分能看到上图中的报错。这个信息暂时不足以分析问题。向前追溯日志一直到最开始的错误信息，可以看到，在online磁盘的操作发起以后，对应每个磁盘都有如下报错：

WARNING: group 4/0xff88596d (SSDDG) disk 0: disk size(762496M) is smaller than disk header value(763097M) 

报错的字面意思很明白：磁盘头元信息记录的磁盘大小（763097M）要大于磁盘的实际大小（762496M）。紧跟着是如下信息：

NOTE: process _rbal_+asm1 (16016) initiating offline of disk 0.3915950646 (SSDDG_0000) with mask 0x7e in group 4
NOTE: sending set offline flag message 2479816269 to 1 disk(s) in group 4
WARNING: Disk SSDDG_0000 in mode 0x11 is now being offlined
WARNING: Disk SSDDG_0000 in mode 0x11 is now being offlined

到这里，可以推出由于ASM元信息记录的磁盘size超过了实际的size，磁盘在online时自检失败，online动作立刻终止。而后面的ORA-15282报错，只是假象。

下面我想先把这个warning排除，来验证我的推测。

在mos上没有搜到该案例，只能用掌握的那点元数据的知识解决了。首先用kfed把盘头的元数据读取出来，重定向到文本。搜索

763097这个数字，找到了下面这行：

从条目的名称kfdhdb.dsksize也可以看出这个条目记录的是磁盘的大小。在创建ASM磁盘组时，会把盘的大小更新到这个条目，如果没有指定size子句，一般都是磁盘（或者分区）的真实大小。操作系统识别到的磁盘大小可以用fdisk查看到，结果显示两者确实如报错所说，大小有差异。产生差异的原因大家都应该猜到了，对盘做了RAID配置之后，可用大小发生了变化（可能是因为RAID信息占据了更多的磁盘大小，这块谁可以解释比较清楚欢迎提出）。

下面要解决ASM元信息与实际情况不一致的问题。考虑到ASM中可以通过resize命令改变ASM磁盘的可用大小，该操作包括两个方面：更新ASM元信息（disk header和at表等等）和rebalance磁盘组的数据。但是这个操作前提是磁盘需要是online状态。现在出问题这些磁盘online都会报错，因此需要非常规手段先让online这一步成功：

首先用kfed read命令将磁盘头数据重定向到文本文件中，然后vi编辑本，将dsksize的值修改成762496，最后将改过的文本kfed merge到原磁盘。

做这个操作时我有几点考虑：
1、asm磁盘头的元信息在1号au的倒数第二个块有备份，如果修改元数据发生意外，可以用kfed repair修复；
2、导出的元数据的文本，也可以作为一个备份。
3、先对其中一块磁盘做修改，试试效果。
对其中一块ASM磁盘完成以上操作之后，在ASM中做online该单块磁盘的动作就成功了。有了这个验证之后，再将所有的ssddg磁盘的dsksize都改掉并在ASM中online起来。
用asmcmd命令行的lsdsk命令去看盘的大小时，发现确实是修改后的762496M。

之后在mos搜到了另外一个报错，有相同的解决方法，见（doc id 1077175.1） ASM disk group mount fails with ORA15036: disk <name> is truncated。
有兴趣的同学可以参考《解密Oracle ASM 内核》这本书中的ASM元信息AT表，stride等相关知识，去验证：resize这一步除了更新磁盘头部记录的磁盘可用大小以外，还会更新at表最后一个块记录的可用au的信息等等元数据；而且resize动作发起之后，asm会对现有数据做rebalance。而手工使用kfed修改，只会改变磁盘头部记录的磁盘可用大小。