Oracle ASM 翻译系列第三十弹：高级知识 Physical metadata replicationPhysical metadata replication

从版本12.1开始，asm会对某些物理元数据做一份复制，具体的说是每个磁盘的第一个au（0号au）上元数据。这意味着，asm同时维护着两份磁盘头、fst（free space table）表、at（allocation table）表的数据。需要注意的是asm对这些数据采用的是复制（replicate），而不是镜像（mirror）。asm镜像（mirror）意味着把一份数据，拷贝到不同磁盘上；而物理元数据的副本位于相同的磁盘，因此使用的术语复制（replicate）。这意味着在external冗余的磁盘组中，物理元数据也会被复制。

pst也是物理元数据，但是asm是通过镜像，而不是复制来提供数据保护。因此只有在normal和high冗余的磁盘组中，pst表存在数据的冗余。

物理元数据位于每块asm磁盘的0号au。元数据复制的特性打开后，asm会把0号au的内容拷贝到11号au，然后同时维护这两份副本。创建磁盘组时如果指定或修改了一个已经存在的磁盘组的compatibility属性为12.1及以上，该特性会自动被打开。

当提升asm compatibility属性值为12.1及以上时，如果11号au有数据，asm将把这些数据移动到别处，然后将物理元数据复制到11号au。

从版本11.1.0.7开始，asm在1号au的倒数第二个块维护了一份磁盘头的副本。在版本12.1中，asm仍然维护着这个副本数据。也就是说，现在每个asm磁盘，有磁盘头的三个副本。

通过查询磁盘组的属性phys_meta_replicated可以确认物理元数据复制的状态。比如下面这个例子：

$ asmcmd lsattr -g data -l phys_meta_replicated

name value

phys_meta_replicated true

phys_meta_replicated值为true意味着磁盘组data的物理元数据已经做了复制。

asm磁盘头的fdhdb.flags条目指代了物理元数据的复制状态：

· kfdhdb.flags = 0 -- 元数据没有复制

· kfdhdb.flags = 1 -- 元数据已经复制完毕

· kfdhdb.flags = 2 -- 元数据在复制过程中

一旦kfdhdb.flags被设置为1，就再也不会回到0.

如前面所述，在asm兼容性设置为12.1或更高的磁盘组中，物理元数据会做复制。 下面通过两个例子来验证前面的结论：

1. 磁盘组的asm兼容性设置为12.1：

$ asmcmd lsattr -g data -l compatible.asm

compatible.asm 12.1.0.0.0

这里显示物理元数据已经被复制。下面确认该磁盘组里的所有磁盘kfdhdb.flags被设为1：

$ for disk in `asmcmd lsdsk -g data --suppressheader`; do kfed read $disk | egrep

"dskname|flags"; done

kfdhdb.dskname: data_0000 ; 0x028: length=9

kfdhdb.flags: 1 ; 0x0fc: 0x00000001

kfdhdb.dskname: data_0001 ; 0x028: length=9

kfdhdb.dskname: data_0002 ; 0x028: length=9

kfdhdb.dskname: data_0003 ; 0x028: length=9

可以看到所有磁盘的kfdhdb.flags都被设为1，也就是该磁盘组里所有的磁盘都做了物理元数据复制。

1. 我们来看下磁盘组的asm compatibility为11.2，然后提升至12.1会是什么情况：

sql> create diskgroup dg1 external redundancy

2 disk '/dev/sdi1'

3 attribute 'compatible.asm'='11.2';

diskgroup created.

看一下复制的状态：

$ asmcmd lsattr -g dg1 -l phys_meta_replicated

可以看到，由于asm兼容性低于12.1，没有physmetareplicated特性。下面通过kfed查看kfdhdb.flags参数，按照之前的结论，值应该为0：

$ kfed read /dev/sdi1 | egrep "type|dskname|grpname|flags"

kfbh.type: 1 ; 0x002: kfbtyp_diskhead

kfdhdb.dskname: dg1_0000 ; 0x028: length=8

kfdhdb.grpname: dg1 ; 0x048: length=3

kfdhdb.flags: 0 ; 0x0fc: 0x00000000

现在把asm兼容性修改到12.1：

$ asmcmd setattr -g dg1 compatible.asm 12.1.0.0.0

确认下复制的状态：

物理元数据做了复制，所以kfdhdb.flags应该设置为1：

$ kfed read /dev/sdi1 | egrep "dskname|flags"

物理元数据应该被复制到11号au：

$ kfed read /dev/sdi1 aun=11 | egrep "type|dskname|flags"

$ kfed read /dev/sdi1 aun=11 blkn=1 | grep type

kfbh.type: 2 ; 0x002: kfbtyp_freespc

$ kfed read /dev/sdi1 aun=11 blkn=2 | grep type

kfbh.type: 3 ; 0x002: kfbtyp_alloctbl

这里显示11号au中有了一份0号au的数据副本。

最后确认下1号au中的磁盘头副本：

$ kfed read /dev/sdi1 aun=1 blkn=254 | grep type

结果显示在1号au的倒数第二个块中存在一份磁盘头副本。

12版本的asm会把0号au的数据在相同磁盘的11号au做一份复制。这种特性可以让asm在磁盘的0号au发生数据损坏时，自动恢复数据。需要注意的是，在external冗余的磁盘组中，如果是物理元数据以外的数据发生丢失，asm都不能做恢复。在normal冗余的磁盘组中，一个failgroup中的一块或多块磁盘有任何的数据丢失，asm都可以做恢复。在high冗余的磁盘组中，任意两个failgroup中的一块或多块磁盘有任何数据丢失，asm都可以做恢复。

<b>本文来自云栖社区合作伙伴“dbgeek”</b>