当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块变更描述
我们可以通过查询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"...
0 3 1 asmdisk6
1 3 0 asmdisk5
2 4 1 asmdisk6
10 8 1 asmdisk6
11 rows selected.
接下来使用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.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.lge[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具体内容就没有什么意义，所以在此我们也不深究了。
本篇只是一个说明性质的文章，只为完结asm元信息系列文章，一些过于细节的地方也不必深究，明白asm acd的内部工作机理也没有太大的实践益处。
<b>本文来自云栖社区合作伙伴“dbgeek”</b>
![oracle中的start with connect by用法[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)