转载

ASM 翻译系列第三十一弹：了解ASM文件的空间分配

原作者：Bane Radulovic

译者：邱大龙

审核：魏兴华

DBGeeK社区联合出品

How many allocation units per file

本文主要是对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。

Bytes vs space

视图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 space

下面的查询（在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，不会被做复制。