#ASM 翻译系列第三十一弹：ASM INTERNAL How many allocation units per file

待我称王封你为后i 2022-07-12 12:07 155阅读 0赞

> **原文：** [How many allocation units per file][]  
> **作者：** Bane Radulovic  
> **译者：**邱大龙，沃趣科技数据库技术专家，主要参与公司产品实施、测试、维护以及优化。对SQL优化、数据迁移、备份容灾等有深入的研究，对大数据量数据迁移、故障恢复、高并发下数据库性能调优有丰富的经验。  
> **审校：**魏兴华  
> **责编：**仲培艺

本文主要是对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，不会被做复制。

### Conclusion ###

ASM空间的占用取决于2个因素：文件的实际大小和磁盘组的冗余度。

在external冗余的磁盘组中，空间的占用：文件实际大小+1个AU（文件头）+1个额外的AU（如果文件大于60个AU）。

在一个normal冗余的磁盘组中，空间的占用：两倍的文件实际大小+2个AU（文件头）+3个额外的AU（如果文件大于60个AU）。

在一个high冗余的磁盘组中，空间的占用：三倍的文件实际大小+3个AU（文件头）+3个额外的AU（如果文件大于60个AU）。

[How many allocation units per file]: http://asmsupportguy.blogspot.jp/2013/06/how-many-allocation-units-per-file.html