当前位置：Oracle研究中心 > 故障案例 >
【学习笔记】Oracle 11G ASM datafile的au分布情况
时间:2016-12-05 22:12 来源:Oracle研究中心 作者:网络 点击: 次
天萃荷净
Oracle研究中心学习笔记：分享一篇关于Oracle 11G ASM的文档，详细介绍asm 的au size不为1m的情况下，datafile的au 分布是怎么样的。
本站文章除注明转载外，均为本站原创： 转载自love wife & love life —Roger 的Oracle技术博客
本文链接地址: Oracle 11g asm中不同au size下datafile的au分布初探
今天有朋友问11g中asm 的au size不为1m的情况下，datafile的au 分布是怎么样的？通过10g的方式去kfed read，发现不对了，原帖地址：~~【高手请进】在oracle11g中通过kfed找到ASM AU空间分布信息？
下午花了一点时间研究了一下，其中还有些没有明白，不过基本上搞清楚了，下面是简单的实验过程：
开始我也没明白其中的关系，首先尝试用strace 去跟踪amdu的过程，我们知道amdu是可以直接抽取datafile的，开始我是这样想的：既然amdu在读取asm disk的时候，可以直接将文件读取出来，那么也就比如需要现在知道该datafile的au 分布情况，于是我使用strace 进行跟踪，完全没有搞明白，如下：
命令如下：strace -o amdu.log amdu -dis ‘/dev/sdb’ -extract data2.256
其中产生的部分log信息如下：
stat64("/dev/sdb", {st_mode=S_IFBLK|0777, st_rdev=makedev(8, 16), ...}) = 0
access("/dev/sdb", F_OK) = 0
statfs("/dev/sdb", {f_type=0x1021994, f_bsize=4096, f_blocks=129388, f_bfree=129358, f_bavail=129358, f_files=129388, f_ffree=128781, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
open("/dev/sdb", O_RDWR|O_LARGEFILE) = 7
mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb759d000 --257
_llseek(7, 0, [0], SEEK_SET) = 0
read(7, "\1\202\1\1\0\0\0\0\0\0\0\200\2519\325\222\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
_llseek(7, 1048576, [1048576], SEEK_SET) = 0 --256
read(7, "\1\202\3\1\0\1\0\0\0\0\0\200\241 \303\257\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
_llseek(7, 2097152, [2097152], SEEK_SET) = 0 --512
read(7, "\1\202\3\1\0\2\0\0\0\0\0\200\241\374\301\257\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
_llseek(7, 3145728, [3145728], SEEK_SET) = 0 --768
read(7, "\1\202\3\1\0\3\0\0\0\0\0\200\241\275\307\257\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
stat64("/dev/sdb", {st_mode=S_IFBLK|0777, st_rdev=makedev(8, 16), ...}) = 0
access("/dev/sdb", F_OK) = 0
statfs("/dev/sdb", {f_type=0x1021994, f_bsize=4096, f_blocks=129388, f_bfree=129358, f_bavail=129358, f_files=129388, f_ffree=128781, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
open("/dev/sdb", O_RDWR|O_LARGEFILE) = 8
_llseek(8, 8384512, [8384512], SEEK_SET) = 0 ---2047
read(8, "\1\202\23\1\377\7\0\0\0\0\0\200_\204\324\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096
open("/home/ora11g/11.2/grid/rdbms/mesg/amduus.msb", O_RDONLY) = 9
fcntl64(9, F_SETFD, FD_CLOEXEC) = 0
lseek(9, 0, SEEK_SET) = 0
read(9, "\25\23\"\1\23\3\t\t\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 256) = 256
lseek(9, 512, SEEK_SET) = 512
read(9, "Z\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
lseek(9, 1024, SEEK_SET) = 1024
read(9, "\311\0\323\0/\1\223\1Z\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
lseek(9, 2048, SEEK_SET) = 2048
read(9, "\n\0\312\0\1\0D\0\313\0\1\0\\\0\314\0\1\0\200\0\315\0\1\0\257\0\316\0\2\0\333\0"..., 512) = 512
lseek(9, 512, SEEK_SET) = 512
read(9, "Z\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
lseek(9, 1024, SEEK_SET) = 1024
read(9, "\311\0\323\0/\1\223\1Z\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
lseek(9, 1536, SEEK_SET) = 1536
read(9, "\f\0d\0\0\0P\0e\0\1\0q\0f\0\1\0\244\0g\0\1\0\315\0h\0\2\0\334\0"..., 512) = 512
write(2, "AMDU-00204: Disk N0001 is in cur"..., 63) = 63
write(2, "AMDU-00201: Disk N0001: '/dev/sd"..., 35) = 35
write(4, "AMDU-00204: Disk N0001 is in cur"..., 63) = 63
write(4, "AMDU-00201: Disk N0001: '/dev/sd"..., 35) = 35
write(4, "** HEARTBEAT DETECTED **\n", 25) = 25
munmap(0xb759d000, 1052672) = 0
close(7) = 0
close(8) = 0
write(4, " Allocated AU's: 24\n", 30) = 30 ---这里其实是比较关键的，到这里为止，amdu起码就知道了au的分布情况了。
write(4, " Free AU's: 488\n", 31) = 31
write(4, " AU's read for dump: 0\n", 29) = 29
write(4, " Block images saved: 0\n", 29) = 29
write(4, " Map lines written: 0\n", 29) = 29
write(4, " Heartbeats seen: 1\n", 29) = 29
write(4, " Corrupt metadata blocks: 0\n", 29) = 29
write(4, " Corrupt AT blocks: 0\n", 29) = 29
write(4, "\n", 1) = 1
write(4, "\n", 1) = 1
write(4, "------------------------ SUMMARY"..., 79) = 79
write(4, " Allocated AU's: 24\n", 30) = 30
write(4, " Free AU's: 488\n", 31) = 31
write(4, " AU's read for dump: 0\n", 29) = 29
write(4, " Block images saved: 0\n", 29) = 29
write(4, " Map lines written: 0\n", 29) = 29
write(4, " Heartbeats seen: 1\n", 29) = 29
write(4, " Corrupt metadata blocks: 0\n", 29) = 29
write(4, " Corrupt AT blocks: 0\n", 29) = 29
write(4, "\n", 1) = 1
首先来看看statfs部分：
statfs("/dev/sdb", {f_type=0x1021994, f_bsize=4096, f_blocks=129388, f_bfree=129358, f_bavail=129358, f_files=129388,f_ffree=128781, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
该函数的结构：
int statfs(const char *path, struct statfs *buf);
该函数的详细参数解析：
struct statfs {
long f_type; /* 文件系统类型 */
long f_bsize; /* 经过优化的传输块大小 */
long f_blocks; /* 文件系统数据块总数 */
long f_bfree; /* 可用块数 */
long f_bavail; /* 非超级用户可获取的块数 */
long f_files; /* 文件结点总数 */
long f_ffree; /* 可用文件结点数 */
fsid_t f_fsid; /* 文件系统标识 */
long f_namelen; /* 文件名的最大长度 */
};
从上面可以得出整个/dev/sdb的情况如下：
block大小为4096;
总的block为：129388个
可用的block为：129358 ---所以用掉的block也就是30个。
关于llseek函数：
_llseek(8, 8384512, [8384512], SEEK_SET) = 0
关于该函数的描述为：_llseek - reposition read/write file offset
8384512 指的是offset，由于block大小为4096，所以8384512/4096=2047
纠结了一段时间，上面的东西，看的眼睛都花了，也没有搞清楚是怎么一个具体的关系，无奈又回到老方法上去。
SQL> conn /AS sysasm
Connected.
SQL> CREATE diskgroup data2 external redundancy disk '/dev/sdb' ATTRIBUTE 'au_size' = '4M';
Diskgroup created.
SQL>
SQL> SELECT
2 name group_name
3 , sector_size sector_size
4 , block_size block_size
5 , allocation_unit_size allocation_unit_size
6 , state state
7 , TYPE TYPE
8 , total_mb total_mb
9 , (total_mb - free_mb) used_mb
10 , ROUND((1- (free_mb / total_mb))*100, 2) pct_used
11 FROM
12 v$asm_diskgroup
13 ORDER BY
14 name
15 /
Disk GROUP Sector Block Allocation
Name SIZE SIZE Unit SIZE State TYPE Total SIZE (MB) Used SIZE (MB) Pct. Used
-------------------- ------- ------- ------------ ----------- ------ --------------- -------------- ---------
DATA1 512 4,096 1,048,576 MOUNTED EXTERN 4,096 2,196 53.61
DATA2 512 4,096 4,194,304 MOUNTED EXTERN 2,048 72 3.52
--------------- --------------
Grand Total: 6,144 2,268
---创建一个test 表空间在新的磁盘组上。
SQL> SELECT file_name FROM dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
+DATA1/roger/users01.dbf
+DATA1/roger/sysaux01.dbf
+DATA1/roger/system01.dbf
+DATA1/roger/roger01.dbf
+DATA1/roger/undotbs.dbf
SQL> CREATE tablespace test datafile '+DATA2' SIZE 20m;
Tablespace created.
SQL> SELECT file_name FROM dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
+DATA1/roger/users01.dbf
+DATA1/roger/sysaux01.dbf
+DATA1/roger/system01.dbf
+DATA1/roger/roger01.dbf
+DATA1/roger/undotbs.dbf
+DATA2/roger/datafile/test.256.792368543
6 ROWS selected.
SQL>
SQL> col path FOR a30
SQL> l
1 SELECT a.GROUP_KFFXP, a.DISK_KFFXP, a.AU_KFFXP, b.path
2 FROM x$kffxp a, v$asm_disk b, v$asm_alias c
3 WHERE a.number_kffxp = c.file_number
4 AND a.GROUP_KFFXP = b.group_number
5 AND a.disk_kffxp = b.disk_number
6 AND b.group_number=2
7 AND c.name LIKE '%TEST%'
8* ORDER BY a.AU_KFFXP
SQL> /
GROUP_KFFXP DISK_KFFXP AU_KFFXP PATH
----------- ---------- ---------- ------------------------------
2 0 18 /dev/sdb
2 0 19 /dev/sdb
2 0 20 /dev/sdb
2 0 21 /dev/sdb
2 0 22 /dev/sdb
2 0 23 /dev/sdb
6 ROWS selected.
使用kfed 读取disk au信息：
[ora11g@11gR2test db]$ kfed read /dev/sdb aun=0 blkn=0|grep f1
kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002
[ora11g@11gR2test db]$
[ora11g@11gR2test db]$ kfed read /dev/sdb aun=2 blkn=1|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 513 ; 0x004: T=0 NUMB=0x201
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 2948726368 ; 0x00c: 0xafc1fe60
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdatb10.aunum: 228928 ; 0x000: 0x00037e40
kfdatb10.shrink: 0 ; 0x004: 0x0000
kfdatb10.ub2pad: 12001 ; 0x006: 0x2ee1
kfdatb10.auinfo[0].link.next: 8 ; 0x008: 0x0008
kfdatb10.auinfo[0].link.prev: 8 ; 0x00a: 0x0008
kfdatb10.auinfo[0].free: 0 ; 0x00c: 0x0000
kfdatb10.auinfo[0].total: 0 ; 0x00e: 0x0000
kfdatb10.auinfo[1].link.next: 16 ; 0x010: 0x0010
kfdatb10.auinfo[1].link.prev: 16 ; 0x012: 0x0010
kfdatb10.auinfo[1].free: 0 ; 0x014: 0x0000
kfdatb10.auinfo[1].total: 0 ; 0x016: 0x0000
kfdatb10.auinfo[2].link.next: 24 ; 0x018: 0x0018
kfdatb10.auinfo[2].link.prev: 24 ; 0x01a: 0x0018
kfdatb10.auinfo[2].free: 0 ; 0x01c: 0x0000
kfdatb10.auinfo[2].total: 0 ; 0x01e: 0x0000
kfdatb10.auinfo[3].link.next: 32 ; 0x020: 0x0020
kfdatb10.auinfo[3].link.prev: 32 ; 0x022: 0x0020
kfdatb10.auinfo[3].free: 0 ; 0x024: 0x0000
kfdatb10.auinfo[3].total: 0 ; 0x026: 0x0000
kfdate[0].discriminator: 1 ; 0x028: 0x00000001
kfdate[0].allo.lo: 0 ; 0x028: XNUM=0x0
kfdate[0].allo.hi: 9437183 ; 0x02c: V=1 I=0 H=0 FNUM=0xfffff
kfdate[1].discriminator: 1 ; 0x030: 0x00000001
kfdate[1].allo.lo: 0 ; 0x030: XNUM=0x0
.....省略部分情况
很多人不明白，11g里面，让au size不是1m的情况下，通过去看aun=2，发现对于的au分布是不对的，其实很简单。
我们这里要注意上面的kfdatb10.auinfo[0].link.next: 8 ; 0×008: 0×0008
开始我也不清楚这里是什么意思，我猜测11g应该是在10g的基础上进行扩展，那么也就是说整体结构应该不会变化。
换句话说，也就是这个link.next 也就是下一个对于的AU，我们应该到这个AU里面去找对应的分布。
由于我们前面的test datafile的asm number是256，所以我们直接看第256个即可，这里需要注意一点的是，
对于我这里4m的au size，每个au是可以容纳1024个block的，跟以前1m的情况是不同的。
[ora11g@11gR2test db]$ kfed read /dev/sdb aun=8 blkn=256|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 256 ; 0x004: T=0 NUMB=0x100
kfbh.block.obj: 1 ; 0x008: TYPE=0x0 NUMB=0x1
kfbh.check: 1715174132 ; 0x00c: 0x663b7af4
kfbh.fcn.base: 22 ; 0x010: 0x00000016
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfffdb.node.incarn: 792368543 ; 0x000: A=1 NUMM=0x179d4acf
kfffdb.node.frlist.number: 4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes: 0 ; 0x00c: 0x00000000
kfffdb.lobytes: 20979712 ; 0x010: 0x01402000
kfffdb.xtntcnt: 6 ; 0x014: 0x00000006
kfffdb.xtnteof: 6 ; 0x018: 0x00000006
kfffdb.blkSize: 8192 ; 0x01c: 0x00002000
kfffdb.flags: 17 ; 0x020: O=1 S=0 S=0 D=0 C=1 I=0 R=0 A=0
kfffdb.fileType: 2 ; 0x021: 0x02
kfffdb.dXrs: 17 ; 0x022: SCHE=0x1 NUMB=0x1
kfffdb.iXrs: 17 ; 0x023: SCHE=0x1 NUMB=0x1
kfffdb.dXsiz[0]: 4294967295 ; 0x024: 0xffffffff
kfffdb.dXsiz[1]: 0 ; 0x028: 0x00000000
kfffdb.dXsiz[2]: 0 ; 0x02c: 0x00000000
kfffdb.iXsiz[0]: 4294967295 ; 0x030: 0xffffffff
kfffdb.iXsiz[1]: 0 ; 0x034: 0x00000000
kfffdb.iXsiz[2]: 0 ; 0x038: 0x00000000
kfffdb.xtntblk: 6 ; 0x03c: 0x0006
kfffdb.break: 60 ; 0x03e: 0x003c
kfffdb.priZn: 0 ; 0x040: KFDZN_COLD
kfffdb.secZn: 0 ; 0x041: KFDZN_COLD
kfffdb.ub2spare: 0 ; 0x042: 0x0000
kfffdb.alias[0]: 106 ; 0x044: 0x0000006a
kfffdb.alias[1]: 4294967295 ; 0x048: 0xffffffff
kfffdb.strpwdth: 1 ; 0x04c: 0x01
kfffdb.strpsz: 22 ; 0x04d: 0x16
kfffdb.usmsz: 0 ; 0x04e: 0x0000
kfffdb.crets.hi: 32973654 ; 0x050: HOUR=0x16 DAYS=0x1a MNTH=0x8 YEAR=0x7dc
kfffdb.crets.lo: 1500018688 ; 0x054: USEC=0x0 MSEC=0x21e SECS=0x16 MINS=0x16
kfffdb.modts.hi: 32973654 ; 0x058: HOUR=0x16 DAYS=0x1a MNTH=0x8 YEAR=0x7dc
kfffdb.modts.lo: 0 ; 0x05c: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0
kfffdb.dasz[0]: 0 ; 0x060: 0x00
.....省略部分内容
kfffdb.usm: ; 0x0a0: length=0
kfffde[0].xptr.au: 18 ; 0x4a0: 0x00000012
kfffde[0].xptr.disk: 0 ; 0x4a4: 0x0000
kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk: 56 ; 0x4a7: 0x38
kfffde[1].xptr.au: 19 ; 0x4a8: 0x00000013
kfffde[1].xptr.disk: 0 ; 0x4ac: 0x0000
kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 S=0
kfffde[1].xptr.chk: 57 ; 0x4af: 0x39
kfffde[2].xptr.au: 20 ; 0x4b0: 0x00000014
kfffde[2].xptr.disk: 0 ; 0x4b4: 0x0000
kfffde[2].xptr.flags: 0 ; 0x4b6: L=0 E=0 D=0 S=0
kfffde[2].xptr.chk: 62 ; 0x4b7: 0x3e
kfffde[3].xptr.au: 21 ; 0x4b8: 0x00000015
kfffde[3].xptr.disk: 0 ; 0x4bc: 0x0000
kfffde[3].xptr.flags: 0 ; 0x4be: L=0 E=0 D=0 S=0
kfffde[3].xptr.chk: 63 ; 0x4bf: 0x3f
kfffde[4].xptr.au: 22 ; 0x4c0: 0x00000016
kfffde[4].xptr.disk: 0 ; 0x4c4: 0x0000
kfffde[4].xptr.flags: 0 ; 0x4c6: L=0 E=0 D=0 S=0
kfffde[4].xptr.chk: 60 ; 0x4c7: 0x3c
kfffde[5].xptr.au: 23 ; 0x4c8: 0x00000017
kfffde[5].xptr.disk: 0 ; 0x4cc: 0x0000
kfffde[5].xptr.flags: 0 ; 0x4ce: L=0 E=0 D=0 S=0
kfffde[5].xptr.chk: 61 ; 0x4cf: 0x3d
kfffde[6].xptr.au: 4294967295 ; 0x4d0: 0xffffffff
kfffde[6].xptr.disk: 65535 ; 0x4d4: 0xffff
kfffde[6].xptr.flags: 0 ; 0x4d6: L=0 E=0 D=0 S=0
kfffde[6].xptr.chk: 42 ; 0x4d7: 0x2a
下面我们再来看看au size为8m和16m的情况。
---For AU size 8m、16m
SQL> SELECT STATUS FROM v$instance;
STATUS
------------
OPEN
SQL> DROP tablespace test including contents AND datafiles;
Tablespace dropped.
SQL>
SQL> SELECT instance_name FROM v$instance;
INSTANCE_NAME
----------------
+ASM
SQL> DROP diskgroup data2;
Diskgroup dropped.
SQL> CREATE diskgroup data2 external redundancy disk '/dev/sdb' 'au_size' = '8M';
CREATE diskgroup data2 external redundancy disk '/dev/sdb' 'au_size' = '8M'
*
ERROR at line 1:
ORA-00933: SQL command NOT properly ended
SQL> CREATE diskgroup data2 external redundancy disk '/dev/sdb' ATTRIBUTE 'au_size' = '8M';
Diskgroup created.
SQL> CREATE diskgroup data3 external redundancy disk '/dev/sdc' ATTRIBUTE 'au_size' = '16M';
Diskgroup created.
SQL> SELECT
2 name group_name
3 , sector_size sector_size
4 , block_size block_size
5 , allocation_unit_size allocation_unit_size
6 , state state
7 , TYPE TYPE
8 , total_mb total_mb
9 , (total_mb - free_mb) used_mb
10 , ROUND((1- (free_mb / total_mb))*100, 2) pct_used
11 FROM
12 v$asm_diskgroup
13 ORDER BY
14 name
15 /
Disk GROUP Sector Block Allocation
Name SIZE SIZE Unit SIZE State TYPE Total SIZE (MB) Used SIZE (MB) Pct. Used
-------------------- ------- ------- ------------ ----------- ------ --------------- -------------- ---------
DATA1 512 4,096 1,048,576 MOUNTED EXTERN 4,096 2,196 53.61
DATA2 512 4,096 8,388,608 MOUNTED EXTERN 2,048 104 5.08
DATA3 512 4,096 16,777,216 MOUNTED EXTERN 2,048 160 7.81
Oracleoracleplus.net --------------- --------------
Grand Total: 8,192 2,460
SQL>
SQL> SELECT
2 NVL(a.name, '[CANDIDATE]') disk_group_name
3 , b.path disk_file_path
4 , b.name disk_file_name
5 , b.failgroup disk_file_fail_group
6 , b.total_mb total_mb
7 , (b.total_mb - b.free_mb) used_mb
8 , ROUND((1- (b.free_mb / b.total_mb))*100, 2) pct_used
9 FROM
10 v$asm_diskgroup a RIGHT OUTER JOIN v$asm_disk b USING (group_number)
11 ORDER BY
12 a.name
13 /
Disk GROUP Name Path File Name Fail GROUP File SIZE (MB) Used SIZE (MB) Pct. Used
-------------------- ----------------- -------------------- -------------------- -------------- -------------- ---------
DATA1 /dev/sdd DATA1_0000 DATA1_0000 4,096 2,196 53.61
******************** -------------- --------------
4,096 2,196
DATA2 /dev/sdb DATA2_0000 DATA2_0000 2,048 104 5.08
******************** -------------- --------------
2,048 104
DATA3 /dev/sdc DATA3_0000 DATA3_0000 2,048 160 7.81
******************** -------------- --------------
2,048 160
-------------- --------------
Grand Total: 8,192 2,460
创建test表空间；
SQL> CREATE tablespace test datafile '+DATA2' SIZE 20m;
Tablespace created.
SQL> CREATE tablespace test1 datafile '+DATA3' SIZE 20m;
Tablespace created.
SQL>
SQL> SELECT file_name FROM dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
+DATA1/roger/users01.dbf
+DATA1/roger/sysaux01.dbf
+DATA1/roger/system01.dbf
+DATA1/roger/roger01.dbf
+DATA1/roger/undotbs.dbf
+DATA2/roger/datafile/test.256.792394777
+DATA3/roger/datafile/test1.256.792394799
7 ROWS selected.
SQL>
我们可以看到对于这两个磁盘组，datafile对应的asm file number都是从256开始的。
首先我们来看data2 磁盘组上的test表空间datafile的au 分布，如下：
[ora11g@11gR2test ~]$ kfed read /dev/sdb aun=0 blkn=0|grep f1
kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002
[ora11g@11gR2test ~]$ kfed read /dev/sdb aun=2 blkn=1|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 513 ; 0x004: T=0 NUMB=0x201
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 2948726368 ; 0x00c: 0xafc1fe60
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdatb10.aunum: 228928 ; 0x000: 0x00037e40
kfdatb10.shrink: 0 ; 0x004: 0x0000
kfdatb10.ub2pad: 12001 ; 0x006: 0x2ee1
kfdatb10.auinfo[0].link.next: 8 ; 0x008: 0x0008
kfdatb10.auinfo[0].link.prev: 8 ; 0x00a: 0x0008
kfdatb10.auinfo[0].free: 0 ; 0x00c: 0x0000
kfdatb10.auinfo[0].total: 0 ; 0x00e: 0x0000
kfdatb10.auinfo[1].link.next: 16 ; 0x010: 0x0010
kfdatb10.auinfo[1].link.prev: 16 ; 0x012: 0x0010
kfdatb10.auinfo[1].free: 0 ; 0x014: 0x0000
kfdatb10.auinfo[1].total: 0 ; 0x016: 0x0000
kfdatb10.auinfo[2].link.next: 24 ; 0x018: 0x0018
kfdatb10.auinfo[2].link.prev: 24 ; 0x01a: 0x0018
kfdatb10.auinfo[2].free: 0 ; 0x01c: 0x0000
kfdatb10.auinfo[2].total: 0 ; 0x01e: 0x0000
kfdatb10.auinfo[3].link.next: 32 ; 0x020: 0x0020
kfdatb10.auinfo[3].link.prev: 32 ; 0x022: 0x0020
kfdatb10.auinfo[3].free: 0 ; 0x024: 0x0000
kfdatb10.auinfo[3].total: 0 ; 0x026: 0x0000
.....省略部分内容
这里有点奇怪的是，我们从au 8去定位，发现报错，知道是不是oracle这里有些问题。如下：
[ora11g@11gR2test ~]$ kfed read /dev/sdb aun=8 blkn=256|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 13 ; 0x002: KFBTYP_PST_NONE
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 2147483904 ; 0x004: T=1 NUMB=0x100
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 17662721 ; 0x00c: 0x010d8301
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
ERROR!!!, failed to get the oracore error message
或许是因为我开始也使用了这些AU，然后将其drop，又重建表空间，且分配的空间是一样大。
但是我能够在next的au 里面找到对应的datafile 的au分布情况，如下：
[ora11g@11gR2test ~]$ kfed read /dev/sdb aun=16 blkn=256|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 256 ; 0x004: T=0 NUMB=0x100
kfbh.block.obj: 1 ; 0x008: TYPE=0x0 NUMB=0x1
kfbh.check: 1407468159 ; 0x00c: 0x53e4427f
kfbh.fcn.base: 19 ; 0x010: 0x00000013
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfffdb.node.incarn: 792394777 ; 0x000: A=1 NUMM=0x179d7e0c
kfffdb.node.frlist.number: 4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes: 0 ; 0x00c: 0x00000000
kfffdb.lobytes: 20979712 ; 0x010: 0x01402000
kfffdb.xtntcnt: 3 ; 0x014: 0x00000003
kfffdb.xtnteof: 3 ; 0x018: 0x00000003
kfffdb.blkSize: 8192 ; 0x01c: 0x00002000
kfffdb.flags: 17 ; 0x020: O=1 S=0 S=0 D=0 C=1 I=0 R=0 A=0
kfffdb.fileType: 2 ; 0x021: 0x02
kfffdb.dXrs: 17 ; 0x022: SCHE=0x1 NUMB=0x1
kfffdb.iXrs: 17 ; 0x023: SCHE=0x1 NUMB=0x1
kfffdb.dXsiz[0]: 4294967295 ; 0x024: 0xffffffff
kfffdb.dXsiz[1]: 0 ; 0x028: 0x00000000
kfffdb.dXsiz[2]: 0 ; 0x02c: 0x00000000
kfffdb.iXsiz[0]: 4294967295 ; 0x030: 0xffffffff
kfffdb.iXsiz[1]: 0 ; 0x034: 0x00000000
kfffdb.iXsiz[2]: 0 ; 0x038: 0x00000000
kfffdb.xtntblk: 3 ; 0x03c: 0x0003
kfffdb.break: 60 ; 0x03e: 0x003c
kfffdb.priZn: 0 ; 0x040: KFDZN_COLD
kfffdb.secZn: 0 ; 0x041: KFDZN_COLD
kfffdb.ub2spare: 0 ; 0x042: 0x0000
kfffdb.alias[0]: 106 ; 0x044: 0x0000006a
kfffdb.alias[1]: 4294967295 ; 0x048: 0xffffffff
kfffdb.strpwdth: 1 ; 0x04c: 0x01
kfffdb.strpsz: 23 ; 0x04d: 0x17
kfffdb.usmsz: 0 ; 0x04e: 0x0000
kfffdb.crets.hi: 32973669 ; 0x050: HOUR=0x5 DAYS=0x1b MNTH=0x8 YEAR=0x7dc
kfffdb.crets.lo: 2655528960 ; 0x054: USEC=0x0 MSEC=0x20a SECS=0x24 MINS=0x27
kfffdb.modts.hi: 32973669 ; 0x058: HOUR=0x5 DAYS=0x1b MNTH=0x8 YEAR=0x7dc
kfffdb.modts.lo: 0 ; 0x05c: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0
kfffdb.dasz[0]: 0 ; 0x060: 0x00
.....省略部分信息
kfffdb.spare[10]: 0 ; 0x098: 0x00000000
kfffdb.spare[11]: 0 ; 0x09c: 0x00000000
kfffdb.usm: ; 0x0a0: length=0
kfffde[0].xptr.au: 13 ; 0x4a0: 0x0000000d
kfffde[0].xptr.disk: 0 ; 0x4a4: 0x0000
kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk: 39 ; 0x4a7: 0x27
kfffde[1].xptr.au: 14 ; 0x4a8: 0x0000000e
kfffde[1].xptr.disk: 0 ; 0x4ac: 0x0000
kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 S=0
kfffde[1].xptr.chk: 36 ; 0x4af: 0x24
kfffde[2].xptr.au: 15 ; 0x4b0: 0x0000000f
kfffde[2].xptr.disk: 0 ; 0x4b4: 0x0000
kfffde[2].xptr.flags: 0 ; 0x4b6: L=0 E=0 D=0 S=0
kfffde[2].xptr.chk: 37 ; 0x4b7: 0x25
kfffde[3].xptr.au: 4294967295 ; 0x4b8: 0xffffffff
kfffde[3].xptr.disk: 65535 ; 0x4bc: 0xffff
kfffde[3].xptr.flags: 0 ; 0x4be: L=0 E=0 D=0 S=0
kfffde[3].xptr.chk: 42 ; 0x4bf: 0x2a
接着我们再来看看data3 磁盘组上的，test1 表空间datafile的分布情况：
[ora11g@11gR2test ~]$ kfed read /dev/sdc aun=2 blkn=1|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 513 ; 0x004: T=0 NUMB=0x201
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 2948726368 ; 0x00c: 0xafc1fe60
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdatb10.aunum: 228928 ; 0x000: 0x00037e40
kfdatb10.shrink: 0 ; 0x004: 0x0000
kfdatb10.ub2pad: 12001 ; 0x006: 0x2ee1
kfdatb10.auinfo[0].link.next: 8 ; 0x008: 0x0008
kfdatb10.auinfo[0].link.prev: 8 ; 0x00a: 0x0008
kfdatb10.auinfo[0].free: 0 ; 0x00c: 0x0000
kfdatb10.auinfo[0].total: 0 ; 0x00e: 0x0000
kfdatb10.auinfo[1].link.next: 16 ; 0x010: 0x0010
kfdatb10.auinfo[1].link.prev: 16 ; 0x012: 0x0010
kfdatb10.auinfo[1].free: 0 ; 0x014: 0x0000
kfdatb10.auinfo[1].total: 0 ; 0x016: 0x0000
kfdatb10.auinfo[2].link.next: 24 ; 0x018: 0x0018
kfdatb10.auinfo[2].link.prev: 24 ; 0x01a: 0x0018
kfdatb10.auinfo[2].free: 0 ; 0x01c: 0x0000
kfdatb10.auinfo[2].total: 0 ; 0x01e: 0x0000
kfdatb10.auinfo[3].link.next: 32 ; 0x020: 0x0020
kfdatb10.auinfo[3].link.prev: 32 ; 0x022: 0x0020
kfdatb10.auinfo[3].free: 0 ; 0x024: 0x0000
kfdatb10.auinfo[3].total: 0 ; 0x026: 0x0000
kfdate[0].discriminator: 1 ; 0x028: 0x00000001
kfdate[0].allo.lo: 0 ; 0x028: XNUM=0x0
kfdate[0].allo.hi: 9437183 ; 0x02c: V=1 I=0 H=0 FNUM=0xfffff
kfdate[1].discriminator: 1 ; 0x030: 0x00000001
kfdate[1].allo.lo: 0 ; 0x030: XNUM=0x0
.....省略部分内容
[ora11g@11gR2test ~]$ kfed read /dev/sdc aun=8 blkn=256|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 2304 ; 0x004: T=0 NUMB=0x900
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 2949461921 ; 0x00c: 0xafcd37a1
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdatb10.aunum: 1031296 ; 0x000: 0x000fbc80
kfdatb10.shrink: 0 ; 0x004: 0x0000
kfdatb10.ub2pad: 12001 ; 0x006: 0x2ee1
kfdatb10.auinfo[0].link.next: 8 ; 0x008: 0x0008
kfdatb10.auinfo[0].link.prev: 8 ; 0x00a: 0x0008
kfdatb10.auinfo[0].free: 0 ; 0x00c: 0x0000
kfdatb10.auinfo[0].total: 0 ; 0x00e: 0x0000
kfdatb10.auinfo[1].link.next: 16 ; 0x010: 0x0010
kfdatb10.auinfo[1].link.prev: 16 ; 0x012: 0x0010
kfdatb10.auinfo[1].free: 0 ; 0x014: 0x0000
kfdatb10.auinfo[1].total: 0 ; 0x016: 0x0000
kfdatb10.auinfo[2].link.next: 24 ; 0x018: 0x0018
kfdatb10.auinfo[2].link.prev: 24 ; 0x01a: 0x0018
kfdatb10.auinfo[2].free: 0 ; 0x01c: 0x0000
kfdatb10.auinfo[2].total: 0 ; 0x01e: 0x0000
kfdatb10.auinfo[3].link.next: 32 ; 0x020: 0x0020
kfdatb10.auinfo[3].link.prev: 32 ; 0x022: 0x0020
kfdatb10.auinfo[3].free: 0 ; 0x024: 0x0000
kfdatb10.auinfo[3].total: 0 ; 0x026: 0x0000
kfdate[0].discriminator: 1 ; 0x028: 0x00000001
kfdate[0].allo.lo: 0 ; 0x028: XNUM=0x0
....省略部分内容
[ora11g@11gR2test ~]$ kfed read /dev/sdc aun=32 blkn=256|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 256 ; 0x004: T=0 NUMB=0x100
kfbh.block.obj: 1 ; 0x008: TYPE=0x0 NUMB=0x1
kfbh.check: 2699974988 ; 0x00c: 0xa0ee594c
kfbh.fcn.base: 26 ; 0x010: 0x0000001a
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfffdb.node.incarn: 792394799 ; 0x000: A=1 NUMM=0x179d7e17
kfffdb.node.frlist.number: 4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes: 0 ; 0x00c: 0x00000000
kfffdb.lobytes: 20979712 ; 0x010: 0x01402000
kfffdb.xtntcnt: 2 ; 0x014: 0x00000002
kfffdb.xtnteof: 2 ; 0x018: 0x00000002
kfffdb.blkSize: 8192 ; 0x01c: 0x00002000
kfffdb.flags: 17 ; 0x020: O=1 S=0 S=0 D=0 C=1 I=0 R=0 A=0
kfffdb.fileType: 2 ; 0x021: 0x02
kfffdb.dXrs: 17 ; 0x022: SCHE=0x1 NUMB=0x1
kfffdb.iXrs: 17 ; 0x023: SCHE=0x1 NUMB=0x1
kfffdb.dXsiz[0]: 4294967295 ; 0x024: 0xffffffff
kfffdb.dXsiz[1]: 0 ; 0x028: 0x00000000
kfffdb.dXsiz[2]: 0 ; 0x02c: 0x00000000
kfffdb.iXsiz[0]: 4294967295 ; 0x030: 0xffffffff
kfffdb.iXsiz[1]: 0 ; 0x034: 0x00000000
kfffdb.iXsiz[2]: 0 ; 0x038: 0x00000000
kfffdb.xtntblk: 2 ; 0x03c: 0x0002
kfffdb.break: 60 ; 0x03e: 0x003c
kfffdb.priZn: 0 ; 0x040: KFDZN_COLD
kfffdb.secZn: 0 ; 0x041: KFDZN_COLD
kfffdb.ub2spare: 0 ; 0x042: 0x0000
kfffdb.alias[0]: 106 ; 0x044: 0x0000006a
kfffdb.alias[1]: 4294967295 ; 0x048: 0xffffffff
kfffdb.strpwdth: 1 ; 0x04c: 0x01
kfffdb.strpsz: 24 ; 0x04d: 0x18
kfffdb.usmsz: 0 ; 0x04e: 0x0000
kfffdb.crets.hi: 32973669 ; 0x050: HOUR=0x5 DAYS=0x1b MNTH=0x8 YEAR=0x7dc
kfffdb.crets.lo: 2679979008 ; 0x054: USEC=0x0 MSEC=0x34f SECS=0x3b MINS=0x27
kfffdb.modts.hi: 32973669 ; 0x058: HOUR=0x5 DAYS=0x1b MNTH=0x8 YEAR=0x7dc
kfffdb.modts.lo: 0 ; 0x05c: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0
kfffdb.dasz[0]: 0 ; 0x060: 0x00
.....省略部分内容
kfffdb.spare[11]: 0 ; 0x09c: 0x00000000
kfffdb.usm: ; 0x0a0: length=0
kfffde[0].xptr.au: 10 ; 0x4a0: 0x0000000a
kfffde[0].xptr.disk: 0 ; 0x4a4: 0x0000
kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk: 32 ; 0x4a7: 0x20
kfffde[1].xptr.au: 11 ; 0x4a8: 0x0000000b
kfffde[1].xptr.disk: 0 ; 0x4ac: 0x0000
kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 S=0
kfffde[1].xptr.chk: 33 ; 0x4af: 0x21
kfffde[2].xptr.au: 4294967295 ; 0x4b0: 0xffffffff
kfffde[2].xptr.disk: 65535 ; 0x4b4: 0xffff
kfffde[2].xptr.flags: 0 ; 0x4b6: L=0 E=0 D=0 S=0
kfffde[2].xptr.chk: 42 ; 0x4b7: 0x2a
kfffde[3].xptr.au: 4294967295 ; 0x4b8: 0xffffffff
下面我们来查下x$表，看au的分布查询对否：
SQL> SELECT disk_kffxp, AU_kffxp, xnum_kffxp
2 FROM x$kffxp
3 WHERE group_kffxp = 2
4 AND number_kffxp = 256;
DISK_KFFXP AU_KFFXP XNUM_KFFXP
---------- ---------- ----------
0 13 0
0 14 1
0 15 2
SQL> SELECT disk_kffxp, AU_kffxp, xnum_kffxp
2 FROM x$kffxp
3 WHERE group_kffxp = 3
4 AND number_kffxp = 256;
DISK_KFFXP AU_KFFXP XNUM_KFFXP
---------- ---------- ----------
0 10 0
0 11 1
可以看到，我们前面kfed的操作是正常的，test 表空间占据13,14,15 一共3个AU，每个au为8m。test1表空间一个占据2个AU，每个au大小是16m。
这里要说明一下：asm这里都是以au分配为单位，也就是说最小分配都是一个AU，换句话说也就是AU的整数倍，我前面的datafile都是20m，所以针对8m和16m的AU SIZE来讲，分配需要分配3个和2个。
下面我们将test 表空间的datafileresize一下，来看一个有趣的事情：
SQL> l
1* SELECT file_id,file_name,tablespace_name FROM dba_data_files ORDER BY 1
SQL> /
FILE_ID FILE_NAME TABLESPACE_NAME
---------- ------------------------------------------------------------ ---------------
1 +DATA1/roger/system01.dbf SYSTEM
2 +DATA1/roger/sysaux01.dbf SYSAUX
3 +DATA2/roger/datafile/test.256.792394777 TEST
4 +DATA1/roger/users01.dbf USERS
5 +DATA1/roger/roger01.dbf ROGER
6 +DATA1/roger/undotbs.dbf UNDOTBS
7 +DATA3/roger/datafile/test1.256.792394799 TEST1
7 ROWS selected.
SQL> ALTER DATABASE datafile 3 resize 30m;
DATABASE altered.
SQL>
[ora11g@11gR2test db]$ kfed READ /dev/sdb aun=16 blkn=256|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.TYPE: 4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 256 ; 0x004: T=0 NUMB=0x100
kfbh.block.obj: 1 ; 0x008: TYPE=0x0 NUMB=0x1
kfbh.CHECK: 3166388824 ; 0x00c: 0xbcbb4258
kfbh.fcn.base: 32 ; 0x010: 0x00000020
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfffdb.node.incarn: 792394777 ; 0x000: A=1 NUMM=0x179d7e0c
kfffdb.node.frlist.NUMBER: 4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes: 0 ; 0x00c: 0x00000000
kfffdb.lobytes: 31465472 ; 0x010: 0x01e02000
kfffdb.xtntcnt: 4 ; 0x014: 0x00000004
kfffdb.xtnteof: 4 ; 0x018: 0x00000004
kfffdb.blkSize: 8192 ; 0x01c: 0x00002000
kfffdb.flags: 17 ; 0x020: O=1 S=0 S=0 D=0 C=1 I=0 R=0 A=0
kfffdb.fileType: 2 ; 0x021: 0x02
kfffdb.dXrs: 17 ; 0x022: SCHE=0x1 NUMB=0x1
kfffdb.iXrs: 17 ; 0x023: SCHE=0x1 NUMB=0x1
kfffdb.dXsiz[0]: 4294967295 ; 0x024: 0xffffffff
kfffdb.dXsiz[1]: 0 ; 0x028: 0x00000000
kfffdb.dXsiz[2]: 0 ; 0x02c: 0x00000000
kfffdb.iXsiz[0]: 4294967295 ; 0x030: 0xffffffff
kfffdb.iXsiz[1]: 0 ; 0x034: 0x00000000
kfffdb.iXsiz[2]: 0 ; 0x038: 0x00000000
kfffdb.xtntblk: 4 ; 0x03c: 0x0004
kfffdb.break: 60 ; 0x03e: 0x003c
kfffdb.priZn: 0 ; 0x040: KFDZN_COLD
kfffdb.secZn: 0 ; 0x041: KFDZN_COLD
kfffdb.ub2spare: 0 ; 0x042: 0x0000
kfffdb.alias[0]: 106 ; 0x044: 0x0000006a
kfffdb.alias[1]: 4294967295 ; 0x048: 0xffffffff
kfffdb.strpwdth: 1 ; 0x04c: 0x01
kfffdb.strpsz: 23 ; 0x04d: 0x17
kfffdb.usmsz: 0 ; 0x04e: 0x0000
kfffdb.crets.hi: 32973669 ; 0x050: HOUR=0x5 DAYS=0x1b MNTH=0x8 YEAR=0x7dc
kfffdb.crets.lo: 2655528960 ; 0x054: USEC=0x0 MSEC=0x20a SECS=0x24 MINS=0x27
kfffdb.modts.hi: 32973670 ; 0x058: HOUR=0x6 DAYS=0x1b MNTH=0x8 YEAR=0x7dc
kfffdb.modts.lo: 0 ; 0x05c: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0
kfffdb.dasz[0]: 0 ; 0x060: 0x00
.....省略部分信息
kfffdb.usm: ; 0x0a0: LENGTH=0
kfffde[0].xptr.au: 13 ; 0x4a0: 0x0000000d
kfffde[0].xptr.disk: 0 ; 0x4a4: 0x0000
kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk: 39 ; 0x4a7: 0x27
kfffde[1].xptr.au: 14 ; 0x4a8: 0x0000000e
kfffde[1].xptr.disk: 0 ; 0x4ac: 0x0000
kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 S=0
kfffde[1].xptr.chk: 36 ; 0x4af: 0x24
kfffde[2].xptr.au: 15 ; 0x4b0: 0x0000000f
kfffde[2].xptr.disk: 0 ; 0x4b4: 0x0000
kfffde[2].xptr.flags: 0 ; 0x4b6: L=0 E=0 D=0 S=0
kfffde[2].xptr.chk: 37 ; 0x4b7: 0x25
kfffde[3].xptr.au: 16 ; 0x4b8: 0x00000010
kfffde[3].xptr.disk: 0 ; 0x4bc: 0x0000
kfffde[3].xptr.flags: 0 ; 0x4be: L=0 E=0 D=0 S=0
kfffde[3].xptr.chk: 58 ; 0x4bf: 0x3a
kfffde[4].xptr.au: 4294967295 ; 0x4c0: 0xffffffff
kfffde[4].xptr.disk: 65535 ; 0x4c4: 0xffff
kfffde[4].xptr.flags: 0 ; 0x4c6: L=0 E=0 D=0 S=0
我们可以看到，这里oracle仅仅是增加了一个AU，开始我们是20m，au为8m，所以oracle应该分配3个，或许有人会说，这里又增加了10m，那么oracle应该再分配2个au才对啊。 你可以看到oracle这里并不
是这样的，可见其是多么的聪明！
Oracle研究中心
本站文章除注明转载外，均为本站原创： 转载自love wife & love life —Roger 的Oracle技术博客
本文链接地址: Oracle 11g asm中不同au size下datafile的au分布初探
今天有朋友问11g中asm 的au size不为1m的情况下，datafile的au 分布是怎么样的？通过10g的方式去kfed read，发现不对了，原帖地址：~~【高手请进】在oracle11g中通过kfed找到ASM AU空间分布信息？
下午花了一点时间研究了一下，其中还有些没有明白，不过基本上搞清楚了，下面是简单的实验过程：
开始我也没明白其中的关系，首先尝试用strace 去跟踪amdu的过程，我们知道amdu是可以直接抽取datafile的，开始我是这样想的：既然amdu在读取asm disk的时候，可以直接将文件读取出来，那么也就比如需要现在知道该datafile的au 分布情况，于是我使用strace 进行跟踪，完全没有搞明白，如下：
命令如下：strace -o amdu.log amdu -dis ‘/dev/sdb’ -extract data2.256
其中产生的部分log信息如下：
stat64("/dev/sdb", {st_mode=S_IFBLK|0777, st_rdev=makedev(8, 16), ...}) = 0
access("/dev/sdb", F_OK) = 0
statfs("/dev/sdb", {f_type=0x1021994, f_bsize=4096, f_blocks=129388, f_bfree=129358, f_bavail=129358, f_files=129388, f_ffree=128781, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
open("/dev/sdb", O_RDWR|O_LARGEFILE) = 7
mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb759d000 --257
_llseek(7, 0, [0], SEEK_SET) = 0
read(7, "\1\202\1\1\0\0\0\0\0\0\0\200\2519\325\222\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
_llseek(7, 1048576, [1048576], SEEK_SET) = 0 --256
read(7, "\1\202\3\1\0\1\0\0\0\0\0\200\241 \303\257\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
_llseek(7, 2097152, [2097152], SEEK_SET) = 0 --512
read(7, "\1\202\3\1\0\2\0\0\0\0\0\200\241\374\301\257\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
_llseek(7, 3145728, [3145728], SEEK_SET) = 0 --768
read(7, "\1\202\3\1\0\3\0\0\0\0\0\200\241\275\307\257\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
stat64("/dev/sdb", {st_mode=S_IFBLK|0777, st_rdev=makedev(8, 16), ...}) = 0
access("/dev/sdb", F_OK) = 0
statfs("/dev/sdb", {f_type=0x1021994, f_bsize=4096, f_blocks=129388, f_bfree=129358, f_bavail=129358, f_files=129388, f_ffree=128781, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
open("/dev/sdb", O_RDWR|O_LARGEFILE) = 8
_llseek(8, 8384512, [8384512], SEEK_SET) = 0 ---2047
read(8, "\1\202\23\1\377\7\0\0\0\0\0\200_\204\324\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096
open("/home/ora11g/11.2/grid/rdbms/mesg/amduus.msb", O_RDONLY) = 9
fcntl64(9, F_SETFD, FD_CLOEXEC) = 0
lseek(9, 0, SEEK_SET) = 0
read(9, "\25\23\"\1\23\3\t\t\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 256) = 256
lseek(9, 512, SEEK_SET) = 512
read(9, "Z\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
lseek(9, 1024, SEEK_SET) = 1024
read(9, "\311\0\323\0/\1\223\1Z\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
lseek(9, 2048, SEEK_SET) = 2048
read(9, "\n\0\312\0\1\0D\0\313\0\1\0\\\0\314\0\1\0\200\0\315\0\1\0\257\0\316\0\2\0\333\0"..., 512) = 512
lseek(9, 512, SEEK_SET) = 512
read(9, "Z\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
lseek(9, 1024, SEEK_SET) = 1024
read(9, "\311\0\323\0/\1\223\1Z\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
lseek(9, 1536, SEEK_SET) = 1536
read(9, "\f\0d\0\0\0P\0e\0\1\0q\0f\0\1\0\244\0g\0\1\0\315\0h\0\2\0\334\0"..., 512) = 512
write(2, "AMDU-00204: Disk N0001 is in cur"..., 63) = 63
write(2, "AMDU-00201: Disk N0001: '/dev/sd"..., 35) = 35
write(4, "AMDU-00204: Disk N0001 is in cur"..., 63) = 63
write(4, "AMDU-00201: Disk N0001: '/dev/sd"..., 35) = 35
write(4, "** HEARTBEAT DETECTED **\n", 25) = 25
munmap(0xb759d000, 1052672) = 0
close(7) = 0
close(8) = 0
write(4, " Allocated AU's: 24\n", 30) = 30 ---这里其实是比较关键的，到这里为止，amdu起码就知道了au的分布情况了。
write(4, " Free AU's: 488\n", 31) = 31
write(4, " AU's read for dump: 0\n", 29) = 29
write(4, " Block images saved: 0\n", 29) = 29
write(4, " Map lines written: 0\n", 29) = 29
write(4, " Heartbeats seen: 1\n", 29) = 29
write(4, " Corrupt metadata blocks: 0\n", 29) = 29
write(4, " Corrupt AT blocks: 0\n", 29) = 29
write(4, "\n", 1) = 1
write(4, "\n", 1) = 1
write(4, "------------------------ SUMMARY"..., 79) = 79
write(4, " Allocated AU's: 24\n", 30) = 30
write(4, " Free AU's: 488\n", 31) = 31
write(4, " AU's read for dump: 0\n", 29) = 29
write(4, " Block images saved: 0\n", 29) = 29
write(4, " Map lines written: 0\n", 29) = 29
write(4, " Heartbeats seen: 1\n", 29) = 29
write(4, " Corrupt metadata blocks: 0\n", 29) = 29
write(4, " Corrupt AT blocks: 0\n", 29) = 29
write(4, "\n", 1) = 1
首先来看看statfs部分：
statfs("/dev/sdb", {f_type=0x1021994, f_bsize=4096, f_blocks=129388, f_bfree=129358, f_bavail=129358, f_files=129388,f_ffree=128781, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
该函数的结构：
int statfs(const char *path, struct statfs *buf);
该函数的详细参数解析：
struct statfs {
long f_type; /* 文件系统类型 */
long f_bsize; /* 经过优化的传输块大小 */
long f_blocks; /* 文件系统数据块总数 */
long f_bfree; /* 可用块数 */
long f_bavail; /* 非超级用户可获取的块数 */
long f_files; /* 文件结点总数 */
long f_ffree; /* 可用文件结点数 */
fsid_t f_fsid; /* 文件系统标识 */
long f_namelen; /* 文件名的最大长度 */
};
从上面可以得出整个/dev/sdb的情况如下：
block大小为4096;
总的block为：129388个
可用的block为：129358 ---所以用掉的block也就是30个。
关于llseek函数：
_llseek(8, 8384512, [8384512], SEEK_SET) = 0
关于该函数的描述为：_llseek - reposition read/write file offset
8384512 指的是offset，由于block大小为4096，所以8384512/4096=2047
纠结了一段时间，上面的东西，看的眼睛都花了，也没有搞清楚是怎么一个具体的关系，无奈又回到老方法上去。
SQL> conn /AS sysasm
Connected.
SQL> CREATE diskgroup data2 external redundancy disk '/dev/sdb' ATTRIBUTE 'au_size' = '4M';
Diskgroup created.
SQL>
SQL> SELECT
2 name group_name
3 , sector_size sector_size
4 , block_size block_size
5 , allocation_unit_size allocation_unit_size
6 , state state
7 , TYPE TYPE
8 , total_mb total_mb
9 , (total_mb - free_mb) used_mb
10 , ROUND((1- (free_mb / total_mb))*100, 2) pct_used
11 FROM
12 v$asm_diskgroup
13 ORDER BY
14 name
15 /
Disk GROUP Sector Block Allocation
Name SIZE SIZE Unit SIZE State TYPE Total SIZE (MB) Used SIZE (MB) Pct. Used
-------------------- ------- ------- ------------ ----------- ------ --------------- -------------- ---------
DATA1 512 4,096 1,048,576 MOUNTED EXTERN 4,096 2,196 53.61
DATA2 512 4,096 4,194,304 MOUNTED EXTERN 2,048 72 3.52
--------------- --------------
Grand Total: 6,144 2,268
---创建一个test 表空间在新的磁盘组上。
SQL> SELECT file_name FROM dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
+DATA1/roger/users01.dbf
+DATA1/roger/sysaux01.dbf
+DATA1/roger/system01.dbf
+DATA1/roger/roger01.dbf
+DATA1/roger/undotbs.dbf
SQL> CREATE tablespace test datafile '+DATA2' SIZE 20m;
Tablespace created.
SQL> SELECT file_name FROM dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
+DATA1/roger/users01.dbf
+DATA1/roger/sysaux01.dbf
+DATA1/roger/system01.dbf
+DATA1/roger/roger01.dbf
+DATA1/roger/undotbs.dbf
+DATA2/roger/datafile/test.256.792368543
6 ROWS selected.
SQL>
SQL> col path FOR a30
SQL> l
1 SELECT a.GROUP_KFFXP, a.DISK_KFFXP, a.AU_KFFXP, b.path
2 FROM x$kffxp a, v$asm_disk b, v$asm_alias c
3 WHERE a.number_kffxp = c.file_number
4 AND a.GROUP_KFFXP = b.group_number
5 AND a.disk_kffxp = b.disk_number
6 AND b.group_number=2
7 AND c.name LIKE '%TEST%'
8* ORDER BY a.AU_KFFXP
SQL> /
GROUP_KFFXP DISK_KFFXP AU_KFFXP PATH
----------- ---------- ---------- ------------------------------
2 0 18 /dev/sdb
2 0 19 /dev/sdb
2 0 20 /dev/sdb
2 0 21 /dev/sdb
2 0 22 /dev/sdb
2 0 23 /dev/sdb
6 ROWS selected.
使用kfed 读取disk au信息：
[ora11g@11gR2test db]$ kfed read /dev/sdb aun=0 blkn=0|grep f1
kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002
[ora11g@11gR2test db]$
[ora11g@11gR2test db]$ kfed read /dev/sdb aun=2 blkn=1|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 513 ; 0x004: T=0 NUMB=0x201
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 2948726368 ; 0x00c: 0xafc1fe60
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdatb10.aunum: 228928 ; 0x000: 0x00037e40
kfdatb10.shrink: 0 ; 0x004: 0x0000
kfdatb10.ub2pad: 12001 ; 0x006: 0x2ee1
kfdatb10.auinfo[0].link.next: 8 ; 0x008: 0x0008
kfdatb10.auinfo[0].link.prev: 8 ; 0x00a: 0x0008
kfdatb10.auinfo[0].free: 0 ; 0x00c: 0x0000
kfdatb10.auinfo[0].total: 0 ; 0x00e: 0x0000
kfdatb10.auinfo[1].link.next: 16 ; 0x010: 0x0010
kfdatb10.auinfo[1].link.prev: 16 ; 0x012: 0x0010
kfdatb10.auinfo[1].free: 0 ; 0x014: 0x0000
kfdatb10.auinfo[1].total: 0 ; 0x016: 0x0000
kfdatb10.auinfo[2].link.next: 24 ; 0x018: 0x0018
kfdatb10.auinfo[2].link.prev: 24 ; 0x01a: 0x0018
kfdatb10.auinfo[2].free: 0 ; 0x01c: 0x0000
kfdatb10.auinfo[2].total: 0 ; 0x01e: 0x0000
kfdatb10.auinfo[3].link.next: 32 ; 0x020: 0x0020
kfdatb10.auinfo[3].link.prev: 32 ; 0x022: 0x0020
kfdatb10.auinfo[3].free: 0 ; 0x024: 0x0000
kfdatb10.auinfo[3].total: 0 ; 0x026: 0x0000
kfdate[0].discriminator: 1 ; 0x028: 0x00000001
kfdate[0].allo.lo: 0 ; 0x028: XNUM=0x0
kfdate[0].allo.hi: 9437183 ; 0x02c: V=1 I=0 H=0 FNUM=0xfffff
kfdate[1].discriminator: 1 ; 0x030: 0x00000001
kfdate[1].allo.lo: 0 ; 0x030: XNUM=0x0
.....省略部分情况
很多人不明白，11g里面，让au size不是1m的情况下，通过去看aun=2，发现对于的au分布是不对的，其实很简单。
我们这里要注意上面的kfdatb10.auinfo[0].link.next: 8 ; 0×008: 0×0008
开始我也不清楚这里是什么意思，我猜测11g应该是在10g的基础上进行扩展，那么也就是说整体结构应该不会变化。
换句话说，也就是这个link.next 也就是下一个对于的AU，我们应该到这个AU里面去找对应的分布。
由于我们前面的test datafile的asm number是256，所以我们直接看第256个即可，这里需要注意一点的是，
对于我这里4m的au size，每个au是可以容纳1024个block的，跟以前1m的情况是不同的。
[ora11g@11gR2test db]$ kfed read /dev/sdb aun=8 blkn=256|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 256 ; 0x004: T=0 NUMB=0x100
kfbh.block.obj: 1 ; 0x008: TYPE=0x0 NUMB=0x1
kfbh.check: 1715174132 ; 0x00c: 0x663b7af4
kfbh.fcn.base: 22 ; 0x010: 0x00000016
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfffdb.node.incarn: 792368543 ; 0x000: A=1 NUMM=0x179d4acf
kfffdb.node.frlist.number: 4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes: 0 ; 0x00c: 0x00000000
kfffdb.lobytes: 20979712 ; 0x010: 0x01402000
kfffdb.xtntcnt: 6 ; 0x014: 0x00000006
kfffdb.xtnteof: 6 ; 0x018: 0x00000006
kfffdb.blkSize: 8192 ; 0x01c: 0x00002000
kfffdb.flags: 17 ; 0x020: O=1 S=0 S=0 D=0 C=1 I=0 R=0 A=0
kfffdb.fileType: 2 ; 0x021: 0x02
kfffdb.dXrs: 17 ; 0x022: SCHE=0x1 NUMB=0x1
kfffdb.iXrs: 17 ; 0x023: SCHE=0x1 NUMB=0x1
kfffdb.dXsiz[0]: 4294967295 ; 0x024: 0xffffffff
kfffdb.dXsiz[1]: 0 ; 0x028: 0x00000000
kfffdb.dXsiz[2]: 0 ; 0x02c: 0x00000000
kfffdb.iXsiz[0]: 4294967295 ; 0x030: 0xffffffff
kfffdb.iXsiz[1]: 0 ; 0x034: 0x00000000
kfffdb.iXsiz[2]: 0 ; 0x038: 0x00000000
kfffdb.xtntblk: 6 ; 0x03c: 0x0006
kfffdb.break: 60 ; 0x03e: 0x003c
kfffdb.priZn: 0 ; 0x040: KFDZN_COLD
kfffdb.secZn: 0 ; 0x041: KFDZN_COLD
kfffdb.ub2spare: 0 ; 0x042: 0x0000
kfffdb.alias[0]: 106 ; 0x044: 0x0000006a
kfffdb.alias[1]: 4294967295 ; 0x048: 0xffffffff
kfffdb.strpwdth: 1 ; 0x04c: 0x01
kfffdb.strpsz: 22 ; 0x04d: 0x16
kfffdb.usmsz: 0 ; 0x04e: 0x0000
kfffdb.crets.hi: 32973654 ; 0x050: HOUR=0x16 DAYS=0x1a MNTH=0x8 YEAR=0x7dc
kfffdb.crets.lo: 1500018688 ; 0x054: USEC=0x0 MSEC=0x21e SECS=0x16 MINS=0x16
kfffdb.modts.hi: 32973654 ; 0x058: HOUR=0x16 DAYS=0x1a MNTH=0x8 YEAR=0x7dc
kfffdb.modts.lo: 0 ; 0x05c: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0
kfffdb.dasz[0]: 0 ; 0x060: 0x00
.....省略部分内容
kfffdb.usm: ; 0x0a0: length=0
kfffde[0].xptr.au: 18 ; 0x4a0: 0x00000012
kfffde[0].xptr.disk: 0 ; 0x4a4: 0x0000
kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk: 56 ; 0x4a7: 0x38
kfffde[1].xptr.au: 19 ; 0x4a8: 0x00000013
kfffde[1].xptr.disk: 0 ; 0x4ac: 0x0000
kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 S=0
kfffde[1].xptr.chk: 57 ; 0x4af: 0x39
kfffde[2].xptr.au: 20 ; 0x4b0: 0x00000014
kfffde[2].xptr.disk: 0 ; 0x4b4: 0x0000
kfffde[2].xptr.flags: 0 ; 0x4b6: L=0 E=0 D=0 S=0
kfffde[2].xptr.chk: 62 ; 0x4b7: 0x3e
kfffde[3].xptr.au: 21 ; 0x4b8: 0x00000015
kfffde[3].xptr.disk: 0 ; 0x4bc: 0x0000
kfffde[3].xptr.flags: 0 ; 0x4be: L=0 E=0 D=0 S=0
kfffde[3].xptr.chk: 63 ; 0x4bf: 0x3f
kfffde[4].xptr.au: 22 ; 0x4c0: 0x00000016
kfffde[4].xptr.disk: 0 ; 0x4c4: 0x0000
kfffde[4].xptr.flags: 0 ; 0x4c6: L=0 E=0 D=0 S=0
kfffde[4].xptr.chk: 60 ; 0x4c7: 0x3c
kfffde[5].xptr.au: 23 ; 0x4c8: 0x00000017
kfffde[5].xptr.disk: 0 ; 0x4cc: 0x0000
kfffde[5].xptr.flags: 0 ; 0x4ce: L=0 E=0 D=0 S=0
kfffde[5].xptr.chk: 61 ; 0x4cf: 0x3d
kfffde[6].xptr.au: 4294967295 ; 0x4d0: 0xffffffff
kfffde[6].xptr.disk: 65535 ; 0x4d4: 0xffff
kfffde[6].xptr.flags: 0 ; 0x4d6: L=0 E=0 D=0 S=0
kfffde[6].xptr.chk: 42 ; 0x4d7: 0x2a
下面我们再来看看au size为8m和16m的情况。
---For AU size 8m、16m
SQL> SELECT STATUS FROM v$instance;
STATUS
------------
OPEN
SQL> DROP tablespace test including contents AND datafiles;
Tablespace dropped.
SQL>
SQL> SELECT instance_name FROM v$instance;
INSTANCE_NAME
----------------
+ASM
SQL> DROP diskgroup data2;
Diskgroup dropped.
SQL> CREATE diskgroup data2 external redundancy disk '/dev/sdb' 'au_size' = '8M';
CREATE diskgroup data2 external redundancy disk '/dev/sdb' 'au_size' = '8M'
*
ERROR at line 1:
ORA-00933: SQL command NOT properly ended
SQL> CREATE diskgroup data2 external redundancy disk '/dev/sdb' ATTRIBUTE 'au_size' = '8M';
Diskgroup created.
SQL> CREATE diskgroup data3 external redundancy disk '/dev/sdc' ATTRIBUTE 'au_size' = '16M';
Diskgroup created.
SQL> SELECT
2 name group_name
3 , sector_size sector_size
4 , block_size block_size
5 , allocation_unit_size allocation_unit_size
6 , state state
7 , TYPE TYPE
8 , total_mb total_mb
9 , (total_mb - free_mb) used_mb
10 , ROUND((1- (free_mb / total_mb))*100, 2) pct_used
11 FROM
12 v$asm_diskgroup
13 ORDER BY
14 name
15 /
Disk GROUP Sector Block Allocation
Name SIZE SIZE Unit SIZE State TYPE Total SIZE (MB) Used SIZE (MB) Pct. Used
-------------------- ------- ------- ------------ ----------- ------ --------------- -------------- ---------
DATA1 512 4,096 1,048,576 MOUNTED EXTERN 4,096 2,196 53.61
DATA2 512 4,096 8,388,608 MOUNTED EXTERN 2,048 104 5.08
DATA3 512 4,096 16,777,216 MOUNTED EXTERN 2,048 160 7.81
Oracleoracleplus.net --------------- --------------
Grand Total: 8,192 2,460
SQL>
SQL> SELECT
2 NVL(a.name, '[CANDIDATE]') disk_group_name
3 , b.path disk_file_path
4 , b.name disk_file_name
5 , b.failgroup disk_file_fail_group
6 , b.total_mb total_mb
7 , (b.total_mb - b.free_mb) used_mb
8 , ROUND((1- (b.free_mb / b.total_mb))*100, 2) pct_used
9 FROM
10 v$asm_diskgroup a RIGHT OUTER JOIN v$asm_disk b USING (group_number)
11 ORDER BY
12 a.name
13 /
Disk GROUP Name Path File Name Fail GROUP File SIZE (MB) Used SIZE (MB) Pct. Used
-------------------- ----------------- -------------------- -------------------- -------------- -------------- ---------
DATA1 /dev/sdd DATA1_0000 DATA1_0000 4,096 2,196 53.61
******************** -------------- --------------
4,096 2,196
DATA2 /dev/sdb DATA2_0000 DATA2_0000 2,048 104 5.08
******************** -------------- --------------
2,048 104
DATA3 /dev/sdc DATA3_0000 DATA3_0000 2,048 160 7.81
******************** -------------- --------------
2,048 160
-------------- --------------
Grand Total: 8,192 2,460
创建test表空间；
SQL> CREATE tablespace test datafile '+DATA2' SIZE 20m;
Tablespace created.
SQL> CREATE tablespace test1 datafile '+DATA3' SIZE 20m;
Tablespace created.
SQL>
SQL> SELECT file_name FROM dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
+DATA1/roger/users01.dbf
+DATA1/roger/sysaux01.dbf
+DATA1/roger/system01.dbf
+DATA1/roger/roger01.dbf
+DATA1/roger/undotbs.dbf
+DATA2/roger/datafile/test.256.792394777
+DATA3/roger/datafile/test1.256.792394799
7 ROWS selected.
SQL>
我们可以看到对于这两个磁盘组，datafile对应的asm file number都是从256开始的。
首先我们来看data2 磁盘组上的test表空间datafile的au 分布，如下：
[ora11g@11gR2test ~]$ kfed read /dev/sdb aun=0 blkn=0|grep f1
kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002
[ora11g@11gR2test ~]$ kfed read /dev/sdb aun=2 blkn=1|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 513 ; 0x004: T=0 NUMB=0x201
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 2948726368 ; 0x00c: 0xafc1fe60
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdatb10.aunum: 228928 ; 0x000: 0x00037e40
kfdatb10.shrink: 0 ; 0x004: 0x0000
kfdatb10.ub2pad: 12001 ; 0x006: 0x2ee1
kfdatb10.auinfo[0].link.next: 8 ; 0x008: 0x0008
kfdatb10.auinfo[0].link.prev: 8 ; 0x00a: 0x0008
kfdatb10.auinfo[0].free: 0 ; 0x00c: 0x0000
kfdatb10.auinfo[0].total: 0 ; 0x00e: 0x0000
kfdatb10.auinfo[1].link.next: 16 ; 0x010: 0x0010
kfdatb10.auinfo[1].link.prev: 16 ; 0x012: 0x0010
kfdatb10.auinfo[1].free: 0 ; 0x014: 0x0000
kfdatb10.auinfo[1].total: 0 ; 0x016: 0x0000
kfdatb10.auinfo[2].link.next: 24 ; 0x018: 0x0018
kfdatb10.auinfo[2].link.prev: 24 ; 0x01a: 0x0018
kfdatb10.auinfo[2].free: 0 ; 0x01c: 0x0000
kfdatb10.auinfo[2].total: 0 ; 0x01e: 0x0000
kfdatb10.auinfo[3].link.next: 32 ; 0x020: 0x0020
kfdatb10.auinfo[3].link.prev: 32 ; 0x022: 0x0020
kfdatb10.auinfo[3].free: 0 ; 0x024: 0x0000
kfdatb10.auinfo[3].total: 0 ; 0x026: 0x0000
.....省略部分内容
这里有点奇怪的是，我们从au 8去定位，发现报错，知道是不是oracle这里有些问题。如下：
[ora11g@11gR2test ~]$ kfed read /dev/sdb aun=8 blkn=256|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 13 ; 0x002: KFBTYP_PST_NONE
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 2147483904 ; 0x004: T=1 NUMB=0x100
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 17662721 ; 0x00c: 0x010d8301
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
ERROR!!!, failed to get the oracore error message
或许是因为我开始也使用了这些AU，然后将其drop，又重建表空间，且分配的空间是一样大。
但是我能够在next的au 里面找到对应的datafile 的au分布情况，如下：
[ora11g@11gR2test ~]$ kfed read /dev/sdb aun=16 blkn=256|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 256 ; 0x004: T=0 NUMB=0x100
kfbh.block.obj: 1 ; 0x008: TYPE=0x0 NUMB=0x1
kfbh.check: 1407468159 ; 0x00c: 0x53e4427f
kfbh.fcn.base: 19 ; 0x010: 0x00000013
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfffdb.node.incarn: 792394777 ; 0x000: A=1 NUMM=0x179d7e0c
kfffdb.node.frlist.number: 4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes: 0 ; 0x00c: 0x00000000
kfffdb.lobytes: 20979712 ; 0x010: 0x01402000
kfffdb.xtntcnt: 3 ; 0x014: 0x00000003
kfffdb.xtnteof: 3 ; 0x018: 0x00000003
kfffdb.blkSize: 8192 ; 0x01c: 0x00002000
kfffdb.flags: 17 ; 0x020: O=1 S=0 S=0 D=0 C=1 I=0 R=0 A=0
kfffdb.fileType: 2 ; 0x021: 0x02
kfffdb.dXrs: 17 ; 0x022: SCHE=0x1 NUMB=0x1
kfffdb.iXrs: 17 ; 0x023: SCHE=0x1 NUMB=0x1
kfffdb.dXsiz[0]: 4294967295 ; 0x024: 0xffffffff
kfffdb.dXsiz[1]: 0 ; 0x028: 0x00000000
kfffdb.dXsiz[2]: 0 ; 0x02c: 0x00000000
kfffdb.iXsiz[0]: 4294967295 ; 0x030: 0xffffffff
kfffdb.iXsiz[1]: 0 ; 0x034: 0x00000000
kfffdb.iXsiz[2]: 0 ; 0x038: 0x00000000
kfffdb.xtntblk: 3 ; 0x03c: 0x0003
kfffdb.break: 60 ; 0x03e: 0x003c
kfffdb.priZn: 0 ; 0x040: KFDZN_COLD
kfffdb.secZn: 0 ; 0x041: KFDZN_COLD
kfffdb.ub2spare: 0 ; 0x042: 0x0000
kfffdb.alias[0]: 106 ; 0x044: 0x0000006a
kfffdb.alias[1]: 4294967295 ; 0x048: 0xffffffff
kfffdb.strpwdth: 1 ; 0x04c: 0x01
kfffdb.strpsz: 23 ; 0x04d: 0x17
kfffdb.usmsz: 0 ; 0x04e: 0x0000
kfffdb.crets.hi: 32973669 ; 0x050: HOUR=0x5 DAYS=0x1b MNTH=0x8 YEAR=0x7dc
kfffdb.crets.lo: 2655528960 ; 0x054: USEC=0x0 MSEC=0x20a SECS=0x24 MINS=0x27
kfffdb.modts.hi: 32973669 ; 0x058: HOUR=0x5 DAYS=0x1b MNTH=0x8 YEAR=0x7dc
kfffdb.modts.lo: 0 ; 0x05c: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0
kfffdb.dasz[0]: 0 ; 0x060: 0x00
.....省略部分信息
kfffdb.spare[10]: 0 ; 0x098: 0x00000000
kfffdb.spare[11]: 0 ; 0x09c: 0x00000000
kfffdb.usm: ; 0x0a0: length=0
kfffde[0].xptr.au: 13 ; 0x4a0: 0x0000000d
kfffde[0].xptr.disk: 0 ; 0x4a4: 0x0000
kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk: 39 ; 0x4a7: 0x27
kfffde[1].xptr.au: 14 ; 0x4a8: 0x0000000e
kfffde[1].xptr.disk: 0 ; 0x4ac: 0x0000
kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 S=0
kfffde[1].xptr.chk: 36 ; 0x4af: 0x24
kfffde[2].xptr.au: 15 ; 0x4b0: 0x0000000f
kfffde[2].xptr.disk: 0 ; 0x4b4: 0x0000
kfffde[2].xptr.flags: 0 ; 0x4b6: L=0 E=0 D=0 S=0
kfffde[2].xptr.chk: 37 ; 0x4b7: 0x25
kfffde[3].xptr.au: 4294967295 ; 0x4b8: 0xffffffff
kfffde[3].xptr.disk: 65535 ; 0x4bc: 0xffff
kfffde[3].xptr.flags: 0 ; 0x4be: L=0 E=0 D=0 S=0
kfffde[3].xptr.chk: 42 ; 0x4bf: 0x2a
接着我们再来看看data3 磁盘组上的，test1 表空间datafile的分布情况：
[ora11g@11gR2test ~]$ kfed read /dev/sdc aun=2 blkn=1|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 513 ; 0x004: T=0 NUMB=0x201
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 2948726368 ; 0x00c: 0xafc1fe60
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdatb10.aunum: 228928 ; 0x000: 0x00037e40
kfdatb10.shrink: 0 ; 0x004: 0x0000
kfdatb10.ub2pad: 12001 ; 0x006: 0x2ee1
kfdatb10.auinfo[0].link.next: 8 ; 0x008: 0x0008
kfdatb10.auinfo[0].link.prev: 8 ; 0x00a: 0x0008
kfdatb10.auinfo[0].free: 0 ; 0x00c: 0x0000
kfdatb10.auinfo[0].total: 0 ; 0x00e: 0x0000
kfdatb10.auinfo[1].link.next: 16 ; 0x010: 0x0010
kfdatb10.auinfo[1].link.prev: 16 ; 0x012: 0x0010
kfdatb10.auinfo[1].free: 0 ; 0x014: 0x0000
kfdatb10.auinfo[1].total: 0 ; 0x016: 0x0000
kfdatb10.auinfo[2].link.next: 24 ; 0x018: 0x0018
kfdatb10.auinfo[2].link.prev: 24 ; 0x01a: 0x0018
kfdatb10.auinfo[2].free: 0 ; 0x01c: 0x0000
kfdatb10.auinfo[2].total: 0 ; 0x01e: 0x0000
kfdatb10.auinfo[3].link.next: 32 ; 0x020: 0x0020
kfdatb10.auinfo[3].link.prev: 32 ; 0x022: 0x0020
kfdatb10.auinfo[3].free: 0 ; 0x024: 0x0000
kfdatb10.auinfo[3].total: 0 ; 0x026: 0x0000
kfdate[0].discriminator: 1 ; 0x028: 0x00000001
kfdate[0].allo.lo: 0 ; 0x028: XNUM=0x0
kfdate[0].allo.hi: 9437183 ; 0x02c: V=1 I=0 H=0 FNUM=0xfffff
kfdate[1].discriminator: 1 ; 0x030: 0x00000001
kfdate[1].allo.lo: 0 ; 0x030: XNUM=0x0
.....省略部分内容
[ora11g@11gR2test ~]$ kfed read /dev/sdc aun=8 blkn=256|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 2304 ; 0x004: T=0 NUMB=0x900
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 2949461921 ; 0x00c: 0xafcd37a1
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdatb10.aunum: 1031296 ; 0x000: 0x000fbc80
kfdatb10.shrink: 0 ; 0x004: 0x0000
kfdatb10.ub2pad: 12001 ; 0x006: 0x2ee1
kfdatb10.auinfo[0].link.next: 8 ; 0x008: 0x0008
kfdatb10.auinfo[0].link.prev: 8 ; 0x00a: 0x0008
kfdatb10.auinfo[0].free: 0 ; 0x00c: 0x0000
kfdatb10.auinfo[0].total: 0 ; 0x00e: 0x0000
kfdatb10.auinfo[1].link.next: 16 ; 0x010: 0x0010
kfdatb10.auinfo[1].link.prev: 16 ; 0x012: 0x0010
kfdatb10.auinfo[1].free: 0 ; 0x014: 0x0000
kfdatb10.auinfo[1].total: 0 ; 0x016: 0x0000
kfdatb10.auinfo[2].link.next: 24 ; 0x018: 0x0018
kfdatb10.auinfo[2].link.prev: 24 ; 0x01a: 0x0018
kfdatb10.auinfo[2].free: 0 ; 0x01c: 0x0000
kfdatb10.auinfo[2].total: 0 ; 0x01e: 0x0000
kfdatb10.auinfo[3].link.next: 32 ; 0x020: 0x0020
kfdatb10.auinfo[3].link.prev: 32 ; 0x022: 0x0020
kfdatb10.auinfo[3].free: 0 ; 0x024: 0x0000
kfdatb10.auinfo[3].total: 0 ; 0x026: 0x0000
kfdate[0].discriminator: 1 ; 0x028: 0x00000001
kfdate[0].allo.lo: 0 ; 0x028: XNUM=0x0
....省略部分内容
[ora11g@11gR2test ~]$ kfed read /dev/sdc aun=32 blkn=256|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 256 ; 0x004: T=0 NUMB=0x100
kfbh.block.obj: 1 ; 0x008: TYPE=0x0 NUMB=0x1
kfbh.check: 2699974988 ; 0x00c: 0xa0ee594c
kfbh.fcn.base: 26 ; 0x010: 0x0000001a
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfffdb.node.incarn: 792394799 ; 0x000: A=1 NUMM=0x179d7e17
kfffdb.node.frlist.number: 4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes: 0 ; 0x00c: 0x00000000
kfffdb.lobytes: 20979712 ; 0x010: 0x01402000
kfffdb.xtntcnt: 2 ; 0x014: 0x00000002
kfffdb.xtnteof: 2 ; 0x018: 0x00000002
kfffdb.blkSize: 8192 ; 0x01c: 0x00002000
kfffdb.flags: 17 ; 0x020: O=1 S=0 S=0 D=0 C=1 I=0 R=0 A=0
kfffdb.fileType: 2 ; 0x021: 0x02
kfffdb.dXrs: 17 ; 0x022: SCHE=0x1 NUMB=0x1
kfffdb.iXrs: 17 ; 0x023: SCHE=0x1 NUMB=0x1
kfffdb.dXsiz[0]: 4294967295 ; 0x024: 0xffffffff
kfffdb.dXsiz[1]: 0 ; 0x028: 0x00000000
kfffdb.dXsiz[2]: 0 ; 0x02c: 0x00000000
kfffdb.iXsiz[0]: 4294967295 ; 0x030: 0xffffffff
kfffdb.iXsiz[1]: 0 ; 0x034: 0x00000000
kfffdb.iXsiz[2]: 0 ; 0x038: 0x00000000
kfffdb.xtntblk: 2 ; 0x03c: 0x0002
kfffdb.break: 60 ; 0x03e: 0x003c
kfffdb.priZn: 0 ; 0x040: KFDZN_COLD
kfffdb.secZn: 0 ; 0x041: KFDZN_COLD
kfffdb.ub2spare: 0 ; 0x042: 0x0000
kfffdb.alias[0]: 106 ; 0x044: 0x0000006a
kfffdb.alias[1]: 4294967295 ; 0x048: 0xffffffff
kfffdb.strpwdth: 1 ; 0x04c: 0x01
kfffdb.strpsz: 24 ; 0x04d: 0x18
kfffdb.usmsz: 0 ; 0x04e: 0x0000
kfffdb.crets.hi: 32973669 ; 0x050: HOUR=0x5 DAYS=0x1b MNTH=0x8 YEAR=0x7dc
kfffdb.crets.lo: 2679979008 ; 0x054: USEC=0x0 MSEC=0x34f SECS=0x3b MINS=0x27
kfffdb.modts.hi: 32973669 ; 0x058: HOUR=0x5 DAYS=0x1b MNTH=0x8 YEAR=0x7dc
kfffdb.modts.lo: 0 ; 0x05c: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0
kfffdb.dasz[0]: 0 ; 0x060: 0x00
.....省略部分内容
kfffdb.spare[11]: 0 ; 0x09c: 0x00000000
kfffdb.usm: ; 0x0a0: length=0
kfffde[0].xptr.au: 10 ; 0x4a0: 0x0000000a
kfffde[0].xptr.disk: 0 ; 0x4a4: 0x0000
kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk: 32 ; 0x4a7: 0x20
kfffde[1].xptr.au: 11 ; 0x4a8: 0x0000000b
kfffde[1].xptr.disk: 0 ; 0x4ac: 0x0000
kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 S=0
kfffde[1].xptr.chk: 33 ; 0x4af: 0x21
kfffde[2].xptr.au: 4294967295 ; 0x4b0: 0xffffffff
kfffde[2].xptr.disk: 65535 ; 0x4b4: 0xffff
kfffde[2].xptr.flags: 0 ; 0x4b6: L=0 E=0 D=0 S=0
kfffde[2].xptr.chk: 42 ; 0x4b7: 0x2a
kfffde[3].xptr.au: 4294967295 ; 0x4b8: 0xffffffff
下面我们来查下x$表，看au的分布查询对否：
SQL> SELECT disk_kffxp, AU_kffxp, xnum_kffxp
2 FROM x$kffxp
3 WHERE group_kffxp = 2
4 AND number_kffxp = 256;
DISK_KFFXP AU_KFFXP XNUM_KFFXP
---------- ---------- ----------
0 13 0
0 14 1
0 15 2
SQL> SELECT disk_kffxp, AU_kffxp, xnum_kffxp
2 FROM x$kffxp
3 WHERE group_kffxp = 3
4 AND number_kffxp = 256;
DISK_KFFXP AU_KFFXP XNUM_KFFXP
---------- ---------- ----------
0 10 0
0 11 1
可以看到，我们前面kfed的操作是正常的，test 表空间占据13,14,15 一共3个AU，每个au为8m。test1表空间一个占据2个AU，每个au大小是16m。
这里要说明一下：asm这里都是以au分配为单位，也就是说最小分配都是一个AU，换句话说也就是AU的整数倍，我前面的datafile都是20m，所以针对8m和16m的AU SIZE来讲，分配需要分配3个和2个。
下面我们将test 表空间的datafileresize一下，来看一个有趣的事情：
SQL> l
1* SELECT file_id,file_name,tablespace_name FROM dba_data_files ORDER BY 1
SQL> /
FILE_ID FILE_NAME TABLESPACE_NAME
---------- ------------------------------------------------------------ ---------------
1 +DATA1/roger/system01.dbf SYSTEM
2 +DATA1/roger/sysaux01.dbf SYSAUX
3 +DATA2/roger/datafile/test.256.792394777 TEST
4 +DATA1/roger/users01.dbf USERS
5 +DATA1/roger/roger01.dbf ROGER
6 +DATA1/roger/undotbs.dbf UNDOTBS
7 +DATA3/roger/datafile/test1.256.792394799 TEST1
7 ROWS selected.
SQL> ALTER DATABASE datafile 3 resize 30m;
DATABASE altered.
SQL>
[ora11g@11gR2test db]$ kfed READ /dev/sdb aun=16 blkn=256|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.TYPE: 4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 256 ; 0x004: T=0 NUMB=0x100
kfbh.block.obj: 1 ; 0x008: TYPE=0x0 NUMB=0x1
kfbh.CHECK: 3166388824 ; 0x00c: 0xbcbb4258
kfbh.fcn.base: 32 ; 0x010: 0x00000020
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfffdb.node.incarn: 792394777 ; 0x000: A=1 NUMM=0x179d7e0c
kfffdb.node.frlist.NUMBER: 4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes: 0 ; 0x00c: 0x00000000
kfffdb.lobytes: 31465472 ; 0x010: 0x01e02000
kfffdb.xtntcnt: 4 ; 0x014: 0x00000004
kfffdb.xtnteof: 4 ; 0x018: 0x00000004
kfffdb.blkSize: 8192 ; 0x01c: 0x00002000
kfffdb.flags: 17 ; 0x020: O=1 S=0 S=0 D=0 C=1 I=0 R=0 A=0
kfffdb.fileType: 2 ; 0x021: 0x02
kfffdb.dXrs: 17 ; 0x022: SCHE=0x1 NUMB=0x1
kfffdb.iXrs: 17 ; 0x023: SCHE=0x1 NUMB=0x1
kfffdb.dXsiz[0]: 4294967295 ; 0x024: 0xffffffff
kfffdb.dXsiz[1]: 0 ; 0x028: 0x00000000
kfffdb.dXsiz[2]: 0 ; 0x02c: 0x00000000
kfffdb.iXsiz[0]: 4294967295 ; 0x030: 0xffffffff
kfffdb.iXsiz[1]: 0 ; 0x034: 0x00000000
kfffdb.iXsiz[2]: 0 ; 0x038: 0x00000000
kfffdb.xtntblk: 4 ; 0x03c: 0x0004
kfffdb.break: 60 ; 0x03e: 0x003c
kfffdb.priZn: 0 ; 0x040: KFDZN_COLD
kfffdb.secZn: 0 ; 0x041: KFDZN_COLD
kfffdb.ub2spare: 0 ; 0x042: 0x0000
kfffdb.alias[0]: 106 ; 0x044: 0x0000006a
kfffdb.alias[1]: 4294967295 ; 0x048: 0xffffffff
kfffdb.strpwdth: 1 ; 0x04c: 0x01
kfffdb.strpsz: 23 ; 0x04d: 0x17
kfffdb.usmsz: 0 ; 0x04e: 0x0000
kfffdb.crets.hi: 32973669 ; 0x050: HOUR=0x5 DAYS=0x1b MNTH=0x8 YEAR=0x7dc
kfffdb.crets.lo: 2655528960 ; 0x054: USEC=0x0 MSEC=0x20a SECS=0x24 MINS=0x27
kfffdb.modts.hi: 32973670 ; 0x058: HOUR=0x6 DAYS=0x1b MNTH=0x8 YEAR=0x7dc
kfffdb.modts.lo: 0 ; 0x05c: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0
kfffdb.dasz[0]: 0 ; 0x060: 0x00
.....省略部分信息
kfffdb.usm: ; 0x0a0: LENGTH=0
kfffde[0].xptr.au: 13 ; 0x4a0: 0x0000000d
kfffde[0].xptr.disk: 0 ; 0x4a4: 0x0000
kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk: 39 ; 0x4a7: 0x27
kfffde[1].xptr.au: 14 ; 0x4a8: 0x0000000e
kfffde[1].xptr.disk: 0 ; 0x4ac: 0x0000
kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 S=0
kfffde[1].xptr.chk: 36 ; 0x4af: 0x24
kfffde[2].xptr.au: 15 ; 0x4b0: 0x0000000f
kfffde[2].xptr.disk: 0 ; 0x4b4: 0x0000
kfffde[2].xptr.flags: 0 ; 0x4b6: L=0 E=0 D=0 S=0
kfffde[2].xptr.chk: 37 ; 0x4b7: 0x25
kfffde[3].xptr.au: 16 ; 0x4b8: 0x00000010
kfffde[3].xptr.disk: 0 ; 0x4bc: 0x0000
kfffde[3].xptr.flags: 0 ; 0x4be: L=0 E=0 D=0 S=0
kfffde[3].xptr.chk: 58 ; 0x4bf: 0x3a
kfffde[4].xptr.au: 4294967295 ; 0x4c0: 0xffffffff
kfffde[4].xptr.disk: 65535 ; 0x4c4: 0xffff
kfffde[4].xptr.flags: 0 ; 0x4c6: L=0 E=0 D=0 S=0
我们可以看到，这里oracle仅仅是增加了一个AU，开始我们是20m，au为8m，所以oracle应该分配3个，或许有人会说，这里又增加了10m，那么oracle应该再分配2个au才对啊。 你可以看到oracle这里并不
是这样的，可见其是多么的聪明！
--------------------------------------ORACLE-DBA----------------------------------------
最权威、专业的Oracle案例资源汇总之【学习笔记】Oracle 11G ASM datafile的au分布情况
本文由大师惜分飞原创分享，网址：http://www.oracleplus.net/arch/1370.html
