从asm磁盘头自动备份看11g到12c的新特性--Physical_metadata_replication

概述
读取AU11
理论支撑
- 12c 新特性
- 复制的位置--AU11
- 磁盘组属性phys_meta_replicated
- replicate复制过程
- 模拟第AU0彻底损坏
总结

概述

磁盘头（AU0 block0）对于ASM磁盘来说无比重要，ASM 磁盘头的大部分内容仅与本磁盘相关，但也有部分信息与整个磁盘组相关，有些甚至于与整个cluster相关。
所以从10.2.0.5开始，oracle在创建磁盘组的时候，会自动备份磁盘头到另外一个位置，具体在AU1的倒数第二个block。但是不同的ausize，倒数第二个块的位置不同，所以今天写了个kfed循环，查找磁盘头位置
11g

[grid@11gasm ~]$ for ((j=0; j<512; j++));do
for ((i=0; i<1024; i++));do
if kfed read /dev/sde aun=$j blkn=$i aus=4194304| grep KFBTYP_DISKHEAD
then
echo i=$i,j=$j
fi
done;
done
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
i=0,j=0
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD

19c

[grid@19crac1 ~]$ for (( j=0; j<2048; j++ ));do
for (( i=0; i<1024; i++ ));do
if kfed read /dev/sdf aun=$j blkn=$i aus=4194304| grep KFBTYP_DISKHEAD
then
echo i=$i,j=$j
fi
done;
done
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
i=0,j=0
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
i=1022,j=1
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
i=0,j=11

如上，11g的结果在我们的预期内，倒数第二个块为1022，因为aus=4M，元数据块大小为4K，所以一个AU里面有1024个块，0-1023，倒数第二个块为1022.
19c的前面两个结果也如预期，但是还有第三个磁盘头的地方，AU 11 BLOCK 0，意思就是19c有第三个磁盘头的备份。
下面就研究下这个特性
参考asm大神的blog：Physical metadata replication

读取AU11

kfed循环读取AU11个每个块

[grid@19crac1 ~]$ for (( i=0; i<20; i++ ));do  if kfed read /dev/asm_arch01 aun=11 blkn=$i aus=4194304| grep type; then echo i=$i; fi; done
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
i=0
kfbh.type:                            2 ; 0x002: KFBTYP_FREESPC
i=1
kfbh.type:                            3 ; 0x002: KFBTYP_ALLOCTBL
i=2
kfbh.type:                            3 ; 0x002: KFBTYP_ALLOCTBL
i=3
kfbh.type:                            3 ; 0x002: KFBTYP_ALLOCTBL
i=4
kfbh.type:                            3 ; 0x002: KFBTYP_ALLOCTBL
i=5
kfbh.type:                            3 ; 0x002: KFBTYP_ALLOCTBL
i=6
kfbh.type:                            3 ; 0x002: KFBTYP_ALLOCTBL
i=7
kfbh.type:                            3 ; 0x002: KFBTYP_ALLOCTBL
i=8
kfbh.type:                            3 ; 0x002: KFBTYP_ALLOCTBL
i=9
kfbh.type:                            3 ; 0x002: KFBTYP_ALLOCTBL
i=10
.。。。。。。
kfbh.type:                            3 ; 0x002: KFBTYP_ALLOCTBL
i=1020
kfbh.type:                            3 ; 0x002: KFBTYP_ALLOCTBL
i=1021
kfbh.type:                            3 ; 0x002: KFBTYP_ALLOCTBL
i=1022
kfbh.type:                            3 ; 0x002: KFBTYP_ALLOCTBL
i=1023

可以看到，AU11不仅备份了磁盘头，还备份了FST表和AT表。
查看asm alert日志，创建时候也会有明显的物理元数据复制信息：

2020-06-18T17:58:11.284413+08:00
SQL> create diskgroup archdg external redundancy disk ‘/dev/asm_arch01’ ATTRIBUTE ‘AU_SIZE’=‘4M’,‘compatible.asm’=‘19.0’
2020-06-18T17:58:11.387069+08:00
NOTE: Assigning number (1,0) to disk (/dev/asm_arch01)
NOTE: initializing header (replicated) on grp 1 disk ARCHDG_0000
NOTE: initializing header on grp 1 disk ARCHDG_0000
NOTE: Disk 0 in group 1 is assigned fgnum=1
NOTE: initiating PST update: grp = 1
2020-06-18T17:58:11.532313+08:00
GMON updating group 1 at 177 for pid 40, osid 103485
NOTE: set version 0 for asmCompat 19.0.0.0.0 for group 1
NOTE: group ARCHDG: initial PST location: disks 0000
2020-06-18T17:58:11.534464+08:00
NOTE: PST update grp = 1 completed successfully
NOTE: cache registered group ARCHDG 1/0x7EC01BCA
NOTE: cache began mount (first) of group ARCHDG 1/0x7EC01BCA
NOTE: cache is mounting group ARCHDG created on 2020/06/18 17:58:11
NOTE: cache opening disk 0 of grp 1: ARCHDG_0000 path:/dev/asm_arch01
2020-06-18T17:58:11.699421+08:00
*allocate domain 1, valid ? 0
2020-06-18T17:58:11.934821+08:00
NOTE: attached to recovery domain 1
2020-06-18T17:58:11.935184+08:00
NOTE: cache creating group 1/0x7EC01BCA (ARCHDG)
NOTE: cache mounting group 1/0x7EC01BCA (ARCHDG) succeeded
NOTE: allocating F1X0 (replicated) on grp 1 disk ARCHDG_0000
NOTE: allocating F1X0 on grp 1 disk ARCHDG_0000
NOTE: Created Used Space Directory for 1 threads
NOTE: diskgroup must now be re-mounted prior to first use
2020-06-18T17:58:12.030713+08:00
NOTE: cache dismounting (clean) group 1/0x7EC01BCA (ARCHDG)
NOTE: messaging CKPT to quiesce pins Unix process pid: 103485, image: oracle@19crac1 (TNS V1-V3)
2020-06-18T17:58:14.616324+08:00
NOTE: LGWR not being messaged to dismount
2020-06-18T17:58:14.741967+08:00
freeing rdom 1
freeing the fusion rht of pdb 1
2020-06-18T17:58:15.018298+08:00
NOTE: detached from domain 1
2020-06-18T17:58:15.018736+08:00
NOTE: cache dismounted group 1/0x7EC01BCA (ARCHDG)
2020-06-18T17:58:15.063148+08:00
GMON dismounting group 1 at 178 for pid 40, osid 103485
GMON dismounting group 1 at 179 for pid 40, osid 103485
2020-06-18T17:58:15.069070+08:00
NOTE: Disk ARCHDG_0000 in mode 0x7f marked for de-assignment
SUCCESS: diskgroup ARCHDG was created
NOTE: cache deleting context for group ARCHDG 1/0x7ec01bca
NOTE: cache registered group ARCHDG 1/0x96601BCD
NOTE: cache began mount (first) of group ARCHDG 1/0x96601BCD
NOTE: Assigning number (1,0) to disk (/dev/asm_arch01)
2020-06-18T17:58:15.171722+08:00
cluster guid (01cf7779cc844fcdff5cbcc3c9dce03a) generated for PST Hbeat for instance 1
2020-06-18T17:58:21.178847+08:00
NOTE: GMON heartbeating for grp 1 (ARCHDG)
GMON querying group 1 at 182 for pid 40, osid 103485
2020-06-18T17:58:21.181027+08:00
NOTE: cache is mounting group ARCHDG created on 2020/06/18 17:58:11
NOTE: cache opening disk 0 of grp 1: ARCHDG_0000 path:/dev/asm_arch01
NOTE: 06/18/20 17:58:20 ARCHDG.F1X0 found on disk 0 au 10 fcn 0.0 datfmt 1
2020-06-18T17:58:21.181453+08:00
NOTE: cache mounting (first) external redundancy group 1/0x96601BCD (ARCHDG)
2020-06-18T17:58:21.274143+08:00
*allocate domain 1, valid ? 0
2020-06-18T17:58:21.382159+08:00
NOTE: attached to recovery domain 1
2020-06-18T17:58:21.396219+08:00
validate pdb 1, flags x4, valid 0, pdb flags x204
*validated domain 1, flags = 0x200
NOTE: cache recovered group 1 to fcn 0.0
NOTE: redo buffer size is 512 blocks (2105344 bytes)
2020-06-18T17:58:21.400430+08:00
NOTE: LGWR attempting to mount thread 1 for diskgroup 1 (ARCHDG)
NOTE: LGWR found thread 1 closed at ABA 0.11262 lock domain=0 inc#=0 instnum=0
NOTE: LGWR mounted thread 1 for diskgroup 1 (ARCHDG)
NOTE: setting 11.2 start ABA for group ARCHDG thread 1 to 2.0
2020-06-18T17:58:21.404038+08:00
NOTE: LGWR opened thread 1 (ARCHDG) at fcn 0.0 ABA 2.0 lock domain=1 inc#=2 instnum=1 gx.incarn=2522880973 mntstmp=2020/06/18 17:58:21.402000
2020-06-18T17:58:21.404263+08:00
NOTE: cache mounting group 1/0x96601BCD (ARCHDG) succeeded
NOTE: cache ending mount (success) of group ARCHDG number=1 incarn=0x96601bcd
2020-06-18T17:58:21.411035+08:00
NOTE: Instance updated compatible.asm to 19.0.0.0.0 for grp 1 (ARCHDG).
2020-06-18T17:58:21.411691+08:00
NOTE: Instance updated compatible.asm to 19.0.0.0.0 for grp 1 (ARCHDG).
2020-06-18T17:58:21.412238+08:00
NOTE: Instance updated compatible.rdbms to 10.1.0.0.0 for grp 1 (ARCHDG).
2020-06-18T17:58:21.412507+08:00
NOTE: Instance updated compatible.rdbms to 10.1.0.0.0 for grp 1 (ARCHDG).
2020-06-18T17:58:21.415782+08:00
SUCCESS: diskgroup ARCHDG was mounted
2020-06-18T17:58:21.493159+08:00
NOTE: diskgroup resource ora.ARCHDG.dg is online
2020-06-18T17:58:21.503768+08:00
SUCCESS: create diskgroup archdg external redundancy disk ‘/dev/asm_arch01’ ATTRIBUTE ‘AU_SIZE’=‘4M’,‘compatible.asm’=‘19.0’

理论支撑

12c 新特性

从版本12.1开始，ASM会对某些物理元数据做一份复制，具体的说是每个磁盘的第一个AU（AU0）上的元数据。这意味着，ASM同时维护者两份磁盘头、FST表、AT表的数据。需要注意的是ASM对这些
数据采用的是复制（replicate），而不是镜像（mirror）。
ASM镜像（mirror）意味着把一份数据，拷贝到不同磁盘上；而物理元数据的副本位于相同的磁盘，因此使用的是术语复制（replicate）。这意味着在external冗余的磁盘组中，物理元数据也会备复制。
PST也是物理元数据，但是ASM是通过镜像，而不是复制来提供数据保护，因此只有在normal和high同于的磁盘组中，PST表存在数据的冗余。

即磁盘头和FST、AT是通过replicate复制来保护的，而PST还是通过磁盘组normal或者high冗余机制保护的。

复制的位置–AU11

物理元数据位于每个ASM磁盘的AU0。元数据复制特性打开后，ASM回把AU0的内容拷贝到AU11，然后同时维护这两份副本。创建磁盘组时如果指定或者修改了一个已经存在的磁盘组的compatibility属性为
12.1及以上，该特性会自当被打开。
当提升ASM compatibility属性为12.1及以上时，如果AU11有数据，ASM会把这些数据移动到别处，然后将物理元数据复制到11号AU。
从版本11.1.0.7 开始，ASM在AU 1的倒数第二个块维护了一份磁盘头的副本。在版本12.1中，ASM仍然维护着这个副本数据。也就是说，现在每个ASM磁盘，有磁盘头的三个副本。

AU0的结构大概如下：

综上所述，replicate特性可以如下：

磁盘组属性phys_meta_replicated

之所以AU0能replicate到AU11，就是由于磁盘组的phys_meta_replicated 属性。
通过磁盘组的属性phys_meta_replicated 可以确认物理元数据复制的状态。如：
[grid@19crac1 ~]$ asmcmd lsattr -G datadg -lm phys_meta_replicated
Group_Name Name Value RO Sys
DATADG phys_meta_replicated true Y Y

phys_meta_replicated值为true，意味着磁盘组datadg的物理元数据已经做了复制。
ASM磁盘头的kfdhdb.flags条目代表物理元数据的复制状态：
[grid@19crac1 ~]$ kfed read /dev/sdf aun=0 blkn=0 aus=4194304|grep flag
kfdhdb.flags: 1 ; 0x0fc: 0x00000001
kfdhdb.flags=0 --元数据没有复制
kfdhdb.flags=1 --元数据已经复制完毕
kfdhdb.flags=2 --元数据再复制过程中
一旦kfdhdb.flags被置为1，就再也不会回到0

replicate复制过程

我们来看下磁盘组的属性compatible.asm为11.2，然后提升至12.1，会发生什么情况？以此来验证复制的过程
1）在19c的环境中先创建compatible.asm为11.2的磁盘组

SQL> create diskgroup archdg external redundancy disk '/dev/asm_arch01' ATTRIBUTE 'AU_SIZE'='4M','compatible.asm'='11.2';
create diskgroup archdg external redundancy disk '/dev/asm_arch01' ATTRIBUTE 'AU_SIZE'='4M','compatible.asm'='11.2'
*
ERROR at line 1:
ORA-15018: diskgroup cannot be created
ORA-59302: The attribute compatible.asm must be 11.2.0.2.0 or higher.SQL> create diskgroup archdg external redundancy disk '/dev/asm_arch01' ATTRIBUTE 'AU_SIZE'='4M','compatible.asm'='11.2.0.2.0';Diskgroup created.

可见，在19c中，compatible.asm最小支持11.2.0.2.0

[grid@19crac1 ~]$ asmcmd lsattr -G archdg -l
Name                     Value
access_control.enabled   FALSE
access_control.umask     066
au_size                  4194304
cell.smart_scan_capable  FALSE
compatible.asm           11.2.0.2.0
compatible.rdbms         10.1.0.0.0
disk_repair_time         12.0h
idp.boundary             auto
idp.type                 dynamic
sector_size              51[grid@19crac1 ~]$ kfed read /dev/asm_arch01 aun=0 blkn=0 aus=4194304|egrep "type|dskname|grpname|flag"
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
kfdhdb.dskname:             ARCHDG_0000 ; 0x028: length=11
kfdhdb.grpname:                  ARCHDG ; 0x048: length=6
kfdhdb.flags:                         0 ; 0x0fc: 0x00000000

这里可以看到目前compatible.asm为11.2,没有phys_meta_replicated属性.而且此时flag为0，元数据没有复制。

[grid@19crac1 ~]$ kfed read /dev/asm_arch01 aun=11 blkn=0 aus=4194304|egrep "type|dskname|grpname|flag"
kfbh.type:                            8 ; 0x002: KFBTYP_CHNGDIR
[grid@19crac1 ~]$ kfed read /dev/asm_arch01 aun=11 blkn=1 aus=4194304|egrep "type|dskname|grpname|flag"
kfbh.type:                            8 ; 0x002: KFBTYP_CHNGDIR
[grid@19crac1 ~]$ kfed read /dev/asm_arch01 aun=11 blkn=2 aus=4194304|egrep "type|dskname|grpname|flag"
kfbh.type:                            8 ; 0x002: KFBTYP_CHNGDIR

此时AU11也不存储物理元数据。
2）设置asm兼容性参数为12.1

[grid@19crac1 ~]$ asmcmd setattr -G archdg compatible.asm 12.1
[grid@19crac1 ~]$ asmcmd lsattr -G archdg -l
Name                     Value
access_control.enabled   FALSE
access_control.umask     066
au_size                  4194304
cell.smart_scan_capable  FALSE
compatible.asm           12.1.0.0.0
compatible.rdbms         10.1.0.0.0
content.check            FALSE
content.type             data
disk_repair_time         12.0h
failgroup_repair_time    24.0h
idp.boundary             auto
idp.type                 dynamic
phys_meta_replicated     true
sector_size              512
thin_provisioned         FALSE

这里可以看到修改为compatible.asm=12.1之后，出现phys_meta_replicated属性。
重新打开一个窗口观察，可以看到kfdhdb.flags从0变为2，正在复制。再变为1，复制完成。
[grid@19crac1 ~]$ kfed read /dev/asm_arch01 aun=0 blkn=0 aus=4194304|egrep “type|dskname|grpname|flag”
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfdhdb.dskname: TESTDG_0000 ; 0x028: length=11
kfdhdb.grpname: TESTDG ; 0x048: length=6
kfdhdb.flags: 0 ; 0x0fc: 0x00000000
[grid@19crac1 ~]$ kfed read /dev/asm_arch01 aun=0 blkn=0 aus=4194304|egrep “type|dskname|grpname|flag”
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfdhdb.dskname: TESTDG_0000 ; 0x028: length=11
kfdhdb.grpname: TESTDG ; 0x048: length=6
kfdhdb.flags: 2 ; 0x0fc: 0x00000002
[grid@19crac1 ~]$ kfed read /dev/asm_arch01 aun=0 blkn=0 aus=4194304|egrep “type|dskname|grpname|flag”
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfdhdb.dskname: TESTDG_0000 ; 0x028: length=11
kfdhdb.grpname: TESTDG ; 0x048: length=6
kfdhdb.flags: 1 ; 0x0fc: 0x00000001
这里就可以看到kfdhdb.flags为1，在au 11的地方也变为了存储物理元数据的信息

[grid@19crac1 ~]$ kfed read /dev/asm_arch01 aun=11 blkn=0 aus=4194304|egrep “type|dskname|grpname|flag”
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfdhdb.dskname: ARCHDG_0000 ; 0x028: length=11
kfdhdb.grpname: ARCHDG ; 0x048: length=6
kfdhdb.flags: 1 ; 0x0fc: 0x00000001
[grid@19crac1 ~]$ kfed read /dev/asm_arch01 aun=11 blkn=1 aus=4194304|egrep “type|dskname|grpname|flag”
kfbh.type: 2 ; 0x002: KFBTYP_FREESPC
kfdfsb.flag: 1 ; 0x00a: B=1 I=0
[grid@19crac1 ~]$ kfed read /dev/asm_arch01 aun=11 blkn=2 aus=4194304|egrep “type|dskname|grpname|flag”
kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL
[grid@19crac1 ~]$ kfed read /dev/asm_arch01 aun=11 blkn=3 aus=4194304|egrep “type|dskname|grpname|flag”
kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL

当compatible.asm有11.2提升为12.1的时候，asm alert日志会有以下输出：
NOTE: set version 1 for asmCompat 12.1.0.0.0 for group 1
2020-06-18T17:42:50.557752+08:00
NOTE: PST update grp = 1 completed successfully
2020-06-18T17:42:50.557891+08:00
SUCCESS: Advanced compatible.asm to 12.1.0.0.0 for grp 1
2020-06-18T17:42:50.558596+08:00
NOTE: Instance updated compatible.asm to 12.1.0.0.0 for grp 1 (ARCHDG).
2020-06-18T17:42:53.555673+08:00
SUCCESS: /* ASMCMD */ALTER DISKGROUP ARCHDG SET ATTRIBUTE ‘compatible.asm’ = ‘12.1’
2020-06-18T17:42:53.576904+08:00
NOTE: header on disk 0 advanced to format #2 using fcn 0.0
2020-06-18T17:42:53.587708+08:00
NOTE: starting meta-data replication for disk 0 of group ARCHDG at FCN 0.36
NOTE: completed meta-data replication for disk 0 of group ARCHDG at FCN 0.39
2020-06-18T17:42:53.858041+08:00
NOTE: disk 0 (ARCHDG_0000) in group 1 (ARCHDG) was replicated
NOTE: Physical metadata for diskgroup 1 (ARCHDG) was replicated.
日志有明显的提示磁盘组进行物理元数据的复制。

模拟第AU0彻底损坏

1）dd损坏 AU0（我的AU大小为4M）

SQL> alter diskgroup archdg dismount;Diskgroup altered.SQL> select name,state from v$asm_diskgroup;NAME                           STATE
------------------------------ -----------
ARCHDG                         DISMOUNTED
DATADG                         MOUNTED
OCRDG                          MOUNTED
[grid@19crac1 ~]$ dd if=/dev/zero of=/dev/asm_arch01 bs=4K count=1024 conv=notrunc
1024+0 records in
1024+0 records out
4194304 bytes (4.2 MB) copied, 0.00748718 s, 560 MB/s
SQL> alter diskgroup archdg mount;
alter diskgroup archdg mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15017: diskgroup "ARCHDG" cannot be mounted
ORA-15040: diskgroup is incomplete

asm alert日志报错，无法mount：

2020-06-18T17:45:42.229346+08:00
SQL> alter diskgroup archdg mount
2020-06-18T17:45:42.244380+08:00
NOTE: cache registered group ARCHDG 1/0x35201BBE
NOTE: cache began mount (first) of group ARCHDG 1/0x35201BBE
2020-06-18T17:45:42.322332+08:00
ERROR: no read quorum in group: required 2, found 0 disks
2020-06-18T17:45:42.322823+08:00
NOTE: cache dismounting (clean) group 1/0x35201BBE (ARCHDG)
NOTE: messaging CKPT to quiesce pins Unix process pid: 98436, image: oracle@19crac1 (TNS V1-V3)
NOTE: dbwr not being msg'd to dismount
NOTE: LGWR not being messaged to dismount
NOTE: cache dismounted group 1/0x35201BBE (ARCHDG)
NOTE: cache ending mount (fail) of group ARCHDG number=1 incarn=0x35201bbe
NOTE: cache deleting context for group ARCHDG 1/0x35201bbe
2020-06-18T17:45:42.358819+08:00
GMON dismounting group 1 at 161 for pid 45, osid 98436
2020-06-18T17:45:42.361782+08:00
ERROR: diskgroup ARCHDG was not mounted
ORA-15032: not all alterations performed
ORA-15017: diskgroup "ARCHDG" cannot be mounted
ORA-15040: diskgroup is incomplete

kfed查看AU0 的信息，已经彻底损坏

[grid@19crac1 ~]$ kfed  read /dev/asm_arch01 aun=0 blkn=0 aus=4194304|grep type
kfbh.type:                            0 ; 0x002: KFBTYP_INVALID
KFED-00322: invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]
[grid@19crac1 ~]$ kfed  read /dev/asm_arch01 aun=0 blkn=1 aus=4194304|grep type
kfbh.type:                            0 ; 0x002: KFBTYP_INVALID
KFED-00322: invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]
[grid@19crac1 ~]$ kfed  read /dev/asm_arch01 aun=0 blkn=2 aus=4194304|grep type
kfbh.type:                            0 ; 0x002: KFBTYP_INVALID
KFED-00322: invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]

等待几分钟，asm alert日志此时没有任何输出，应该不会自动修复的。
2)手动备份AU11
[grid@19crac1 ~]$ dd if=/dev/asm_arch01 bs=4K count=1024 skip=11264 of=/tmp/au0bak
1024+0 records in
1024+0 records out
4194304 bytes (4.2 MB) copied, 0.0158802 s, 264 MB/s
note：11264是怎么算出来的，AU11，每个AU 4M，要跳过11个AU，即44M，bs=4K，那么最后跳过的个数就为：44*1024/4

检查备份出来的文件是否是AU0的元数据

[grid@19crac1 ~]$ kfed read /tmp/au0bak |more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt:                          2 ; 0x003: 0x02
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:              2147483648 ; 0x008: disk=0
kfbh.check:                  1855652657 ; 0x00c: 0x6e9b0331
kfbh.fcn.base:                       38 ; 0x010: 0x00000026
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr:         ORCLDISK ; 0x000: length=8
kfdhdb.driver.reserved[0]:            0 ; 0x008: 0x00000000
kfdhdb.driver.reserved[1]:            0 ; 0x00c: 0x00000000
kfdhdb.driver.reserved[2]:            0 ; 0x010: 0x00000000
kfdhdb.driver.reserved[3]:            0 ; 0x014: 0x00000000
kfdhdb.driver.reserved[4]:            0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]:            0 ; 0x01c: 0x00000000
kfdhdb.compat:                202375168 ; 0x020: 0x0c100000
kfdhdb.dsknum:                        0 ; 0x024: 0x0000
kfdhdb.grptyp:                        1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:             ARCHDG_0000 ; 0x028: length=11
kfdhdb.grpname:                  ARCHDG ; 0x048: length=6
kfdhdb.fgname:              ARCHDG_0000 ; 0x068: length=11
kfdhdb.siteguid[0]:                   0 ; 0x088: 0x00
kfdhdb.siteguid[1]:                   0 ; 0x089: 0x00
。。。。。

3）还原AU0

[grid@19crac1 ~]$ dd if=/tmp/au0bak of=/dev/asm_arch01 bs=4K conv=notrunc
1024+0 records in
1024+0 records out
4194304 bytes (4.2 MB) copied, 0.013505 s, 311 MB/s
[grid@19crac1 ~]$ kfed read /dev/asm_arch01 aun=0 blkn=0 aus=4194304|egrep "type|dskname|grpname|flag"
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
kfdhdb.dskname:             ARCHDG_0000 ; 0x028: length=11
kfdhdb.grpname:                  ARCHDG ; 0x048: length=6
kfdhdb.flags:                         1 ; 0x0fc: 0x00000001
[grid@19crac1 ~]$ kfed read /dev/asm_arch01 aun=0 blkn=1 aus=4194304|egrep "type|dskname|grpname|flag"
kfbh.type:                            2 ; 0x002: KFBTYP_FREESPC
kfdfsb.flag:                          1 ; 0x00a: B=1 I=0

4）mount磁盘组

[grid@19crac1 ~]$ sqlplus / as sysasmSQL*Plus: Release 19.0.0.0.0 - Production on Thu Jun 18 17:55:09 2020
Version 19.4.0.0.0Copyright (c) 1982, 2019, Oracle.  All rights reserved.Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.4.0.0.0SQL> alter diskgroup archdg mount;Diskgroup altered.SQL> select name,state from v$asm_diskgroup;NAME                           STATE
------------------------------ -----------
DATADG                         MOUNTED
OCRDG                          MOUNTED
ARCHDG                         MOUNTED

asm alert日志：

2020-06-18T17:55:17.134341+08:00
SQL> alter diskgroup archdg mount
2020-06-18T17:55:17.149208+08:00
NOTE: cache registered group ARCHDG 1/0x3E501BC1
NOTE: cache began mount (first) of group ARCHDG 1/0x3E501BC1
NOTE: Assigning number (1,0) to disk (/dev/asm_arch01)
2020-06-18T17:55:17.227733+08:00
cluster guid (01cf7779cc844fcdff5cbcc3c9dce03a) generated for PST Hbeat for instance 1
2020-06-18T17:55:23.234354+08:00
NOTE: GMON heartbeating for grp 1 (ARCHDG)
GMON querying group 1 at 164 for pid 40, osid 102225
2020-06-18T17:55:23.236778+08:00
NOTE: cache is mounting group ARCHDG created on 2020/06/18 17:42:26
NOTE: cache opening disk 0 of grp 1: ARCHDG_0000 path:/dev/asm_arch01
NOTE: 06/18/20 17:55:22 ARCHDG.F1X0 found on disk 0 au 2 fcn 0.0 datfmt 2
2020-06-18T17:55:23.237570+08:00
NOTE: cache mounting (first) external redundancy group 1/0x3E501BC1 (ARCHDG)
2020-06-18T17:55:23.343958+08:00
* allocate domain 1, valid ? 0
2020-06-18T17:55:23.436744+08:00
NOTE: attached to recovery domain 1
2020-06-18T17:55:23.451423+08:00
validate pdb 1, flags x4, valid 0, pdb flags x204
* validated domain 1, flags = 0x200
NOTE: cache recovered group 1 to fcn 0.41
NOTE: redo buffer size is 512 blocks (2105344 bytes)
2020-06-18T17:55:23.454930+08:00
NOTE: LGWR attempting to mount thread 1 for diskgroup 1 (ARCHDG)
NOTE: LGWR found thread 1 closed at ABA 2.26 lock domain=0 inc#=0 instnum=1
NOTE: LGWR mounted thread 1 for diskgroup 1 (ARCHDG)
2020-06-18T17:55:23.457176+08:00
NOTE: LGWR opened thread 1 (ARCHDG) at fcn 0.41 ABA 3.27 lock domain=1 inc#=2 instnum=1 gx.incarn=1045437377 mntstmp=2020/06/18 17:55:23.456000
2020-06-18T17:55:23.457358+08:00
NOTE: cache mounting group 1/0x3E501BC1 (ARCHDG) succeeded
NOTE: cache ending mount (success) of group ARCHDG number=1 incarn=0x3e501bc1
2020-06-18T17:55:23.462428+08:00
NOTE: Instance updated compatible.asm to 12.1.0.0.0 for grp 1 (ARCHDG).
2020-06-18T17:55:23.462955+08:00
NOTE: Instance updated compatible.asm to 12.1.0.0.0 for grp 1 (ARCHDG).
2020-06-18T17:55:23.463444+08:00
NOTE: Instance updated compatible.rdbms to 10.1.0.0.0 for grp 1 (ARCHDG).
2020-06-18T17:55:23.463785+08:00
NOTE: Instance updated compatible.rdbms to 10.1.0.0.0 for grp 1 (ARCHDG).
2020-06-18T17:55:23.465982+08:00
SUCCESS: diskgroup ARCHDG was mounted
2020-06-18T17:55:23.481495+08:00
SUCCESS: alter diskgroup archdg mount
2020-06-18T17:55:23.557721+08:00
NOTE: diskgroup resource ora.ARCHDG.dg is online

总结

1）物理元数据的复制是12c的新特性，主要是由磁盘组的phys_meta_replicated 属性决定；
2）compatible.asm>=12.1的时候，物理元数据复制特性开启，会自动复制AU0到AU11；
3）在12c中，asm disk header 默认会有三份，而AT和FST会有两份。PST依赖磁盘组的冗余度，磁盘组对他没有额外的复制和备份。
4）在12c中，AU0损坏，asm不会自动修复，必须手动还原备份来进行修复；
5)在external冗余的磁盘组中，如果是物理元数据以外的数据发生丢失，ASM都不能做恢复。在normal冗余的磁盘中，一个failgroup中的一块或多块磁盘有任何的数据丢失，ASM都可以做恢复。在high冗余的磁盘中，任意两个failgroup中的一块或多块磁盘有任何数据丢失，ASM都可以做恢复。
6）当创建磁盘组成功时，表示已经将AU0复制到AU11成功，再返回Diskgroup created.成功之前，都是再进行复制的过程中，由kfdfsb.flag=2可以看出。

从asm磁盘头自动备份看11g到12c的新特性--Physical_metadata_replication相关推荐

asm磁盘头自动备份19c-au11
从asm磁盘头自动备份看11g到12c的新特性--Physical_metadata_replication 概述读取AU11 理论支撑 12c 新特性复制的位置--AU11 磁盘组属性phys_ ...
oracle备份磁盘头,ASM 磁盘头信息备份
ASM磁盘头信息保存在每个磁盘的前4K里面,这个信息的备份对于ASM的恢复非常重要,有下面的几种方法 1.直接做dd来备份磁盘的前4K,磁盘头信息丢失时,dd回来备份:dd if=/dev/raw/ ...
ASM磁盘头损坏修复
ASM磁盘头损坏修复查看正常ASM磁盘磁盘头信息 od bbed UE 磁盘头损坏检查 kfed查看 kfed find 磁盘头损坏修复 kfed repair dd 手工重构磁盘头补充---2号 ...
oracle asm磁盘头备份,ASM磁盘头的第三个备份-Physically Addressed Metadata Redundancy
这几天很蕉绿,想着复习下技术.个人很喜欢ASM,就从ASM开始复习.循环kfed发现一个很奇怪的事情,就是,我扫到AU 11的时候发现,居然这个aun的blkn0是KFBTYP_DISKHEAD.要知 ...
【ASM 翻译系列第二弹：ASM 12C 版本新特性】
随着Oracle 12c的发布,也就意味着全新版本的ASM面世了.已知的重大新特性有Flex ASM,数据预校验和更加便捷的磁盘管理操作.下面针对这几个方面进行详细介绍. Flex ASM Flex ...
抢先看！Kubernetes v1.21 新特性一览
作者 | 倪朋飞来源 | 漫谈云原生头图 | 下载于视觉中国 Kubernetes v1.21 下个月就要发布了(v1.21.0 将于 4 月 8 日发布),本文梳理该版本带来的新特性,以便你为下 ...
开发者必看｜Android 8.0 新特性及开发指南
背景介绍谷歌2017I/O开发者大会今年将于5月17-19日在美国加州举办.大会将跟往年一样发布最新的 Android 系统,今年为 Android 8.0.谷歌在今年3 月21日发布 Androi ...
看完 Python3.10 的新特性，我决定仍不更新
Python3.10 在 2021 年的 10 月 3 号发布,目前已经过去好几个月了,关于它的新特性相信大家已经有所耳闻,不过我决定仍然不更新,目前我在用的版本是 Python3.8,没有任何不爽. ...
亲睹芳容：多图看 OS X Yosemite 的新特性
苹果的一举一动总会引来关注.iPhone 6 谍照曝光,火了一时,甚至是指纹识别传感器 Touch ID 的微小变化,也引起了大众的讨论.当然,这一切是因为苹果总为我们带来惊喜,比如当年的 Apple ...

从asm磁盘头自动备份看11g到12c的新特性--Physical_metadata_replication

从asm磁盘头自动备份看11g到12c的新特性--Physical_metadata_replication

概述

读取AU11

理论支撑

12c 新特性

复制的位置–AU11

磁盘组属性phys_meta_replicated

replicate复制过程

模拟第AU0彻底损坏

总结

从asm磁盘头自动备份看11g到12c的新特性--Physical_metadata_replication相关推荐

最新文章

热门文章