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

Physical 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表存在数据的冗余。

Where is the replicated metadata

物理元数据位于每块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磁盘,有磁盘头的三个副本。

Disk group attribute PHYS_META_REPLICATED

通过查询磁盘组的属性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.

Metadata replication in action

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

1. 磁盘组的ASM兼容性设置为12.1:

$ asmcmd lsattr -G DATA -l compatible.asm

Name Value

compatible.asm 12.1.0.0.0

$ asmcmd lsattr -G DATA -l phys_meta_replicated

Name Value

phys_meta_replicated true

这里显示物理元数据已经被复制。下面确认该磁盘组里的所有磁盘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.flags: 1 ; 0x0fc: 0x00000001

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

kfdhdb.flags: 1 ; 0x0fc: 0x00000001

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

kfdhdb.flags: 1 ; 0x0fc: 0x00000001

可以看到所有磁盘的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

Name Value

可以看到,由于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

确认下复制的状态:

$ asmcmd lsattr -G DG1 -l phys_meta_replicated

Name Value

phys_meta_replicated true

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

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

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

kfdhdb.flags: 1 ; 0x0fc: 0x00000001

物理元数据应该被复制到11号AU:

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

kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD

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

kfdhdb.flags: 1 ; 0x0fc: 0x00000001

$ 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

kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD

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

Conclusion

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

时间: 2024-07-31 18:49:39

Oracle ASM 翻译系列第三十弹:高级知识 Physical metadata replication的相关文章

ASM 翻译系列第三十二弹:自制数据抽取小工具

Find block in ASM 在本系列文章[ Where is my data]中,我已经演示了如何从ASM磁盘中定位和抽取一个Oracle的block,为了让这件事做起来不那么复杂,我又写了一个perl脚本find_block.pl来简化整个操作,只需要提供数据文件的名称和需要提取的block,这个脚本就可以输出从ASM磁盘组中抽取块的命令. find_block.pl find_block.pl是一个perl脚本,脚本里集成了dd或kfed命令来从ASM磁盘中抽取一个块,脚本可以在Li

ASM 翻译系列第三十四弹:ASM磁盘组重要属性介绍

ASM Disk Group Attributes 磁盘组的属性是ASM 11.1版本引入的,是磁盘组层面而非ASM实例层面的.磁盘组的属性有一些只能在创建磁盘组时指定,有一些只能在创建之后指定,还有一些可以在任何时候指定. 本篇内容是对本系列文章-[ASM Attributes Directory]的展开. ACCESS_CONTROL.ENABLED ACCESS_CONTROL.ENABLED属性指定了一个磁盘组的ASM File Access Control是否启用,参数的值可以设置为t

ASM 翻译系列第三十五弹:ASM 253号文件——ASM spfile

ASM spfile in a disk group 从ASM版本11.2开始,ASM spfile可以储存在ASM磁盘组里.事实上,在安装ASM时,OUI就已经把ASM spfile放在了磁盘组中.对于单实例环境和集群环境都是这样.在安装过程中创建的第一个磁盘组是spfile的默认位置,但这不是必要的.ASM spfile还是可以放在文件系统上,就是$ORACLE_HOME/dbs目录下. New ASMCMD commands 为支持该特性,ASMCMD引入了新的命令用来备份,复制和移动AS

ASM 翻译系列第三十三弹:REQUIRED_MIRROR_FREE_MB的含义

REQUIRED_MIRROR_FREE_MB REQUIRED_MIRROR_FREE_MB和USABLE_FILE_MB是V$ASM_DISKGROUP[_STAT]视图中非常有趣的两列.Oracle Support部门收到的很多问题是关于这两列的意义以及它们的值是怎么计算的.我本打算写些文章介绍一下,但是我意识到我不可能比Harald van Breederode做的更出色.因此我征得了他的同意来直接参考他的文章,所以还是请欣赏他的大作吧. https://prutser.wordpres

ASM 翻译系列第三十一弹:了解ASM文件的空间分配

How many allocation units per file 本文主要是对ASM文件的空间分配进行一些探讨和研究. ASM空间分配的最小单位是AU,默认的AU size是1MB,但在Exadata下AU 的默认大小是4MB. ASM文件的空间分配是以extent为单位,每一个extent是由一个或多个AU组成,在11.2版本,前20000个extent,每一个extent由1个AU组成,接下来的20000个extent,每一个由4个AU组成,再超出的extent,每一个由16个AU组成.

ASM 翻译系列第三弹:基础知识 About ASM disk groups, disks and files

Oracle ASM使用磁盘组来存放数据文件,每一个ASM的磁盘组由一些ASM磁盘组成,每一个ASM磁盘组本身是一个独立的存储单元,是自描述的,对于ASM磁盘组中数据库文件,ASM提供一个文件系统的接口,方便DBA做管理.存放在ASM磁盘组中的文件被均匀的分布在磁盘组中的所有磁盘上,通过这种方式,每一块磁盘都可以提供一致的性能,同时ASM的性能可以比得上裸设备的性能.[摘录自11GR2版本的ASM官方文档] ASM Disk Groups 一个ASM磁盘组是由一个或多个ASM磁盘组成的,每个AS

Oracle ASM 翻译系列第九弹:ASM Toolbox

本篇文章主要介绍几个大家应该熟练掌握的ASM工具. asmcmd - command line interface to ASM ASM最初发布时,asmcmd的功能还很弱.从11gR2版本开始,asmcmd已经成为一个功能非常强大且常用的工具. ASMCA - ASM configuration assistant ASMCA有两种使用方式,第一种是比较容易使用的图形界面,还有一种是静默方式.虽然图形界面使用频率很高,但静默方式更强大. kfed - ASM metadata editor 前

Oracle ASM 翻译系列第二十五弹:ASM 高级知识 When will my rebalance complete

When will my rebalance complete "磁盘组的rebalance什么时候能完成?",这个问题我经常被问到,但是如果你期望我给出一个具体的数值,那么你会失望,毕竟ASM本身已经给你提供了一个估算值(GV$ASM_OPERATION.EST_MINUTES),其实你想知道的是rebalance完成的精确的时间.虽然我不能给你一个精确的时间,但是我可以给你一些rebalance的操作细节,让你知道当前rebalance是否正在进行中,进行到哪个阶段,以及这个阶段是

Oracle ASM 翻译系列第十四弹:ASM Internal Rebalancing act

在ASM中,每一个文件的extent都均匀的分布在它所在磁盘组的所有磁盘上,无论是在文件第一次创建或是文件创建之后的重新resize都是如此,这也意味着我们始终能保持磁盘组中的每一个磁盘上都有一个平衡的空间分配. Rebalance operation 虽然文件在新建或是resize过程中都能保证空间的均匀分配,但是磁盘组在某些情况下会自动触发重平衡的操作,例如添加.删除和resize磁盘的操作(这些操作显然会让磁盘组变得不再平衡),再如,移动一个文件从磁盘的hot区到cold区.我们还可以通过