ASM 翻译系列第十六弹：ASM Internal ASM Active Change Directory

原作者：Bane Radulovic

译者：    郭旭瑞

审核：    魏兴华

DBGeeK社群联合出品

ASM Active Change Directory

当ASM实例要对多个元信息block进行原子修改时，ASM的active change directory 简称ACD会记录相应的日志，ACD是ASM元信息的3号文件。对应的日志记录会以单次IO的方式写入，来确保操作原子性。ACD被分成多个chunk或者thread，每个运行中的ASM实例都有它自己的42MB大小的chunk。当一个磁盘组被创建时，会分配一个独立的chunk给ACD。随着更多的实例挂载了该磁盘组，ACD的chunk数也会同比例增长，每个实例会使用属于自己的ACD chunk区。ACD包含如下组件：

● ACDC - ACD checkpoint ACD检查点● ABA - ACD block address ACD块地址● LGE - ACD redo log record ACD 重做日志记录●BCD - ACD block change descriptor ACD块变更描述

Locating ASM active change directory

我们可以通过查询X$KFFXP视图来获取ACD目录包含的AU。ACD是元信息3号文件，因此在我们的查询中我们使number_kffxp=3。

SQL> SELECT x.xnum_kffxp "Extent",
x.au_kffxp "AU",
x.disk_kffxp "Disk #",
d.name "Disk name"
FROM x$kffxp x, v$asm_disk_stat d
WHERE x.group_kffxp=d.group_number
and x.disk_kffxp=d.disk_number
and x.group_kffxp=1
and x.number_kffxp=3
ORDER BY 1, 2;

  Extent         AU     Disk # Disk name
---------- ---------- ---------- ---------
       0          4          0 ASMDISK5
       1          2          1 ASMDISK6
       2          5          0 ASMDISK5
...
      39         21          1 ASMDISK6
      40         24          0 ASMDISK5
      41         22          1 ASMDISK6

42 rows selected.

查询返回了42行，即42个AU。当前磁盘组的AU大小为1MB，意味着ACD总大小是42MB。如果我用更大的AU(4MB)来重建该磁盘组，我们仍然会发现ACD大小是42MB。接下来我们创建一个AU为4M的磁盘组验证一下：

SQL> create diskgroup RECO external redundancy
disk 'ORCL:ASMDISK5', 'ORCL:ASMDISK6'
attribute 'au_size'='4M';

Diskgroup created.

现在对X$KFFXP和V$ASM_DISK_STAT视图运行同样的查询返回了11行，说明ACD大小仍为42MB。

SQL> SELECT x.xnum_kffxp "Extent"...

  Extent         AU     Disk # Disk name
---------- ---------- ---------- ---------
       0          3          1 ASMDISK6
       1          3          0 ASMDISK5
       2          4          1 ASMDISK6
...
      10          8          1 ASMDISK6

11 rows selected.

Closer look at ASM active change directory

接下来使用kfed工具对ACD进行查看。上一个查询显示ACD是从ASMDISK6磁盘的第三个AU开始的。考虑到当前磁盘组AU大小为4MB，所以我需要在kfed命令中指定ausz=4m。

$ kfed read /dev/oracleasm/disks/ASMDISK6 ausz=4m aun=3 | more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            7 ; 0x002: KFBTYP_ACDC
...
kfracdc.eyec[0]:                     65 ; 0x000: 0x41
kfracdc.eyec[1]:                     67 ; 0x001: 0x43
kfracdc.eyec[2]:                     68 ; 0x002: 0x44
kfracdc.eyec[3]:                     67 ; 0x003: 0x43
kfracdc.thread:                       1 ; 0x004: 0x00000001
kfracdc.lastAba.seq:         4294967295 ; 0x008: 0xffffffff
kfracdc.lastAba.blk:         4294967295 ; 0x00c: 0xffffffff
kfracdc.blk0:                         1 ; 0x010: 0x00000001
kfracdc.blks:                     11263 ; 0x014: 0x00002bff
kfracdc.ckpt.seq:                     2 ; 0x018: 0x00000002
kfracdc.ckpt.blk:                     2 ; 0x01c: 0x00000002
kfracdc.fcn.base:                    16 ; 0x020: 0x00000010
kfracdc.fcn.wrap:                     0 ; 0x024: 0x00000000
kfracdc.bufBlks:                    512 ; 0x028: 0x00000200
kfracdc.strt112.seq:                  0 ; 0x02c: 0x00000000
kfracdc.strt112.blk:                  0 ; 0x030: 0x00000000
$

输出中kfbh.type=KFBTYP_ACDC证实了这确实是一个ACD block。输出中我们只需要关注一个地方就可以了，那就是kfracdc.thread=1，这代表该ACD属于ASM实例一。在一个集群环境中，该值是与ASM实例号相对应的。以上是ACD的开始，也就是block 0。我们来看一下block 1，也就是ACD的实际数据。

$ kfed read /dev/oracleasm/disks/ASMDISK6 ausz=4m aun=3 blkn=1 | more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            8 ; 0x002: KFBTYP_CHNGDIR
...
kfracdb.lge[0].valid:                 1 ; 0x00c: V=1 B=0 M=0
kfracdb.lge[0].chgCount:              1 ; 0x00d: 0x01
kfracdb.lge[0].len:                  52 ; 0x00e: 0x0034
kfracdb.lge[0].kfcn.base:            13 ; 0x010: 0x0000000d
kfracdb.lge[0].kfcn.wrap:             0 ; 0x014: 0x00000000
kfracdb.lge[0].bcd[0].kfbl.blk:       0 ; 0x018: blk=0
kfracdb.lge[0].bcd[0].kfbl.obj:       4 ; 0x01c: file=4
kfracdb.lge[0].bcd[0].kfcn.base:      0 ; 0x020: 0x00000000
kfracdb.lge[0].bcd[0].kfcn.wrap:      0 ; 0x024: 0x00000000
kfracdb.lg 46 32596 46 14987 0 0 2892 0 0:00:11 0:00:05 0:00:06 2892e[0].bcd[0].oplen:          4 ; 0x028: 0x0004
kfracdb.lge[0].bcd[0].blkIndex:       0 ; 0x02a: 0x0000
kfracdb.lge[0].bcd[0].flags:         28 ; 0x02c: F=0 N=0 F=1 L=1 V=1 A=0 C=0
kfracdb.lge[0].bcd[0].opcode:       212 ; 0x02e: 0x00d4
kfracdb.lge[0].bcd[0].kfbtyp:         9 ; 0x030: KFBTYP_COD_BGO
kfracdb.lge[0].bcd[0].redund:        17 ; 0x031: SCHE=0x1 NUMB=0x1
kfracdb.lge[0].bcd[0].pad:        63903 ; 0x032: 0xf99f
kfracdb.lge[0].bcd[0].KFRCOD_CRASH:   1 ; 0x034: 0x00000001
kfracdb.lge[0].bcd[0].au[0]:          8 ; 0x038: 0x00000008
kfracdb.lge[0].bcd[0].disks[0]:       0 ; 0x03c: 0x0000
...
$

我们看到ACD 1号block的类型是KFBTYP_CHNGDIR，包含了kfracdb.lge[i]数据结构，也就是ASM的redo日志记录。以上信息中我们需要关注2个地方，一个是正在进行中的操作(opcode，即操作码)，另一个是操作类型(kfbtyp)。其实，这些内容脱离了ACD具体内容就没有什么意义，所以在此我们也不深究了。

Conclusion

本篇只是一个说明性质的文章，只为完结ASM元信息系列文章，一些过于细节的地方也不必深究，明白ASM ACD的内部工作机理也没有太大的实践益处。

关于译者

郭旭瑞，沃趣科技产品交付部经理，负责QData Cloud高性能数据库云平台、QBackup数据库秒级备份恢复云平台等产品的整体交付管理与技术支持、维保服务工作。个人网站：www.dbalex.com

往期精彩

关于沃趣

杭州沃趣科技股份有限公司创建于2012年，创始团队为原阿里巴巴数据库及系统运维团队核心骨干，凭借着多年的运维经验，为行业客户提供专业数据库、系统相关的服务和产品；专注为用户提供基于高性能、高可用、可扩展的开放数据库云平台解决方案的国产厂商。

沃趣科技的产品已广泛应用于证券、保险、医疗、广电传媒、银行、电信、能源电力、快递物流、公共事业、大型企业等，为这些行业用户持续提供行业解决方案及服务支持。

研发中心位于杭州，同时在北京、上海、广州、南京、兰州、沈阳建立了分支机构,建立了辐射全国的销售和服务体系。

我们始终坚信，数据是驱动企业创新的源动力！坚持围绕企业数据库做好一件事

                        ——让高性能触手可及！