本文主要是对ASM文件的空间分配进行一些探讨和研究。
ASM空间分配的最小单位是AU，默认的AU size是1MB，但在Exadata下AU 的默认大小是4MB。
ASM文件的空间分配是以extent为单位，每一个extent是由一个或多个AU组成，在11.2版本，前20000个extent，每一个extent由1个AU组成，接下来的20000个extent，每一个由4个AU组成，再超出的extent，每一个由16个AU组成。这个特性被叫做可变extent。而在11.1版本，extent的增长则遵循的是1-8-64倍AU的方式。在版本10，可变extent这个特性还没出现，因此所有的extent的大小都是1个AU。
视图V$ASM_FILE中，有两列是关于空间分配的：BYTES 和 SPACE，它们的定义如下：
BYTES - 文件的大小
SPACE - 文件实际占用的ASM空间的大小
这两列的定义有一些细微的差异，但是这两列的数值差异可能是非常大的，下面我们就来实际的看一下，首先交代一下我的测试环境，ASM和DB的版本为11.2.0.3，使用ASMLIB方式管理的磁盘：
可以通过如下的查询来简单的了解我的环境中磁盘组data的基本情况，例如AU的大小，冗余的级别，我的数据文件大多都位于这个磁盘组中。
SQL> select NAME, GROUP_NUMBER, ALLOCATION_UNIT_SIZE/1024/1024 "AU size (MB)", TYPE from V$ASM_DISKGROUP where NAME='DATA'; NAME GROUP_NUMBER AU size (MB) TYPE ---------------- ------------ ------------ ------ DATA 1 1 NORMAL
现在创建一个小于60个extent的“小”文件和一个大于60个extent的“大”文件。
SQL> create tablespace T1 datafile '+DATA' size 10 M; Tablespace created. SQL> create tablespace T2 datafile '+DATA' size 100 M; Tablespace created. Get the ASM file numbers for those two files: SQL> select NAME, round(BYTES/1024/1024) "MB" from V$DATAFILE; NAME MB ------------------------------------------ ---------- ... +DATA/br/datafile/t1.272.818281717 10 +DATA/br/datafile/t2.271.818281741 100
“小"文件的ASM文件号是272，“大”文件的ASM文件号是271。
接着我们通过前面提到的V$ASM_FILE视图来获取这两个文件的空间占用信息：
SQL> select FILE_NUMBER, round(BYTES/1024/1024) "Bytes (AU)", round(SPACE/1024/1024) "Space (AUs)", REDUNDANCY from V$ASM_FILE where FILE_NUMBER in (271, 272) and GROUP_NUMBER=1; FILE_NUMBER Bytes (AU) Space (AUs) REDUND ----------- ---------- ----------- ------ 272 10 22 MIRROR 271 100 205 MIRROR
bytes字段显示了文件的实际大小，我们小文件的大小为10MB，因此占用了10个AU（AU的size为1MB）,小文件实际占用的ASM空间有22个AU，其中10个AU是实际的数据文件，1个AU为文件头，由于文件是镜像的，因此文件真正占用的ASM空间为：（10+1）*2=22个AU。
对于“大”文件，bytes字段显示了文件的实际大小为100MB也就是100个AU，到现在为止一切推论都跟原理相符，但是接着我们发现大文件的ASM空间占用为205个AU，按照上面的计算应该有202个AU才正确，多出来的3个AU是如何来的？接下来我们就来一窥究竟。
下面的查询（在ASM实例上运行）展示了ASM 271号文件extent的分布情况：
SQL> select XNUM_KFFXP "Virtual extent", PXN_KFFXP "Physical extent", DISK_KFFXP "Disk number", AU_KFFXP "AU number" from X$KFFXP where GROUP_KFFXP=1 and NUMBER_KFFXP=271 order by 1,2; Virtual extent Physical extent Disk number AU number -------------- --------------- ----------- ---------- 0 0 3 1155 0 1 0 1124 1 2 0 1125 1 3 2 1131 2 4 2 1132 2 5 0 1126 ... 100 200 3 1418 100 201 1 1412 2147483648 0 3 1122 2147483648 1 0 1137 2147483648 2 2 1137 205 rows selected.
由于ASM文件是做了镜像的，我们可以看到每一个虚拟extent有两个物理extent，而且位于不同的磁盘（其实还位于不同的failgroup），但是最有趣的是查询结果的最后三行，虚拟extent的号是2147483648，做了3副本。我们可以通过kfed工具看下这个extent的内容，使用kfed我们首先需要知道ASM磁盘的名称。
通过如下查询获得ASM磁盘的名称：
SQL> select DISK_NUMBER, PATH from V$ASM_DISK where GROUP_NUMBER=1; DISK_NUMBER PATH ----------- --------------- 0 ORCL:ASMDISK1 1 ORCL:ASMDISK2 2 ORCL:ASMDISK3 3 ORCL:ASMDISK4
我们来检查下这些AU中具体存放的内容：
$ kfed read /dev/oracleasm/disks/ASMDISK4 aun=1122 | grep type kfbh.type: 12 ; 0x002: KFBTYP_INDIRECT $ kfed read /dev/oracleasm/disks/ASMDISK1 aun=1137 | grep type kfbh.type: 12 ; 0x002: KFBTYP_INDIRECT $ kfed read /dev/oracleasm/disks/ASMDISK3 aun=1137 | grep type kfbh.type: 12 ; 0x002: KFBTYP_INDIRECT
这些额外的AU存放着ASM的元数据，更具体的讲，他们保存了extent map信息，而这些extent map信息不能够存放在ASM的文件目录块中了，因为ASM文件目录块中，只能存放60个extent的条目，一旦超出这个值，那么就要有额外的地方来记录这个信息。由于这属于ASM的元数据，因此被做了3副本（虽然是一个normal冗余的磁盘组），因此每一个大文件都会有这么3个额外的AU，但在一个external冗余的磁盘组中，仅仅只会有这么一个额外的AU，不会被做复制。
ASM空间的占用取决于2个因素：文件的实际大小和磁盘组的冗余度。
在external冗余的磁盘组中，空间的占用：文件实际大小+1个AU（文件头）+1个额外的AU（如果文件大于60个AU）。
在一个normal冗余的磁盘组中，空间的占用：两倍的文件实际大小+2个AU（文件头）+3个额外的AU（如果文件大于60个AU）
在一个high冗余的磁盘组中，空间的占用：三倍的文件实际大小+3个AU（文件头）+3个额外的AU（如果文件大于60个AU）
本文来自云栖社区合作伙伴“DBGEEK”
