第5章 小荷露峥嵘──ASM

ASM 在 Oracle 11g 中的变化从大方面来看可归纳有二。首先，从 DB 中拆分出来，和Clusterware合并在一起，成为了Grid；其次，推出ADVM和ACFS两个新功能，这两个变化的意义非常。

ADVM和ACFS这两个新功能的出现实际是在向世界宣布：ASM不再是Oracle数据库专用方案（在10g时是专用的）。它甚至不介意和Ext这些老牌的通用文件系统PK一下。像这样一个胸怀天下、心系苍生的伟大作品放在DB这样一个小众产品中显然是不合适的。所以，Oracle把它整合到Grid中，显然Oracle这么做是要为这个宏大目标扫清障碍、搭桥铺路。

个人感觉，Oracle对ASM是寄予厚望的，Oracle先是“搭车销售”，把它放在DB中，借着RAC的提携先在人堆里混了个脸熟。接着，再把它从DB中剥离出来、增加通用能力、合并到Clusterware，怎么看都是一套设计好的“组合拳”，如果真是这样，那Oracle这“曲线救国”的发展路线可谓用心良苦了。

比较起来，和 ASM 同时出现的弟兄──OCFS 就没那么顺利了，Oracle 先是把它推给了开源社区，而且也没有做任何“捆绑销售”，所以OCFS的使用情况并不乐观。不过近来在Oracle虚拟化系列产品中，OCFS又重新找到了定位（OCFS是Oracle VM Server中首选的存储方案）。

5.1 ASM架构

ASM（Automatic Storage Management，自动存储管理）是Oracle 10g引入的存储管理方案，在Oracle 10g的RAC中，ASM是以一个“备胎”的姿态出现的，其他同台竞技的备胎还有裸设备、集群文件系统，它只是个“之一”。到了 Oracle 11.2 的 RAC，ASM 已经毫无悬念地被扶成主力，不再是“之一”。这一章中我们先简单回顾一下ASM的基础概念，然后再围绕Oracle 11.2中出现的这些新功能展开。

如果读者用过某种卷管理系统，就能很容易理解ASM的架构。它本质上就是一个卷管理器。ASM的存储空间是这样组织的，如图5-1所示。

图5-1 ASM存储架构

位于存储架构最底层的就是一个个的磁盘，这个磁盘可能是个物理的磁盘，也可能是存储盘柜上的 LUN。ASM 不能直接使用裸盘，必须要经过分区、格式化两个步骤转换成 ASM 磁盘后才可以供ASM使用。

分区是用操作系统的 fdisk 命令完成的，分区之后，磁盘盘头会生成一个分区表，其中记录每个分区的名字和分区的开始、结束边界。目前 ASM 还不能使用整块硬盘，至少在 Grid 11.2.0.2时还不行，因此即便要把整个磁盘交给ASM使用，我们也必须分出一个分区。

做好分区后接下来就要做格式化，这需要用Oracle提供的oracleasm createdisk命令完成，格式化的目的是在磁盘盘头写上ASM的元数据，用来标识这个磁盘是被ASM使用的。Oracle也是通过扫描磁盘盘头的元数据来判断该磁盘是否是ASM磁盘的。

有了 ASM 磁盘后，我们就可以创建 ASM 磁盘组了。磁盘到磁盘组这个设计理念和卷管理器中的卷与卷组概念完全对等。但在 ASM 磁盘组和 ASM 磁盘之间其实还有一个逻辑结 构——Failure Group，这个概念常常会被忽略。这是 ASM 提供的数据冗余（也可以叫做软RAID）。因为在生产环境里，我们通常会使用盘柜RAID卡的硬RAID，所以ASM的软RAID并不常用。但是Grid 11.2 中ASM 的一些新特性是和 Failure Group 相关的，所以我们需要把Failure Group 的概念介绍下。不过之前我们还是先看看Extent和AU这对概念吧。

5.1.1 基础单元──Extent 和 AU

Extent和AU是RDBMS和ASM两个层面的空间分配单位。我们用图5-2来解释这两个概念。图5-2描述的是ASM的存储结构，上半部分是RDBM的存储结构，下半部分是ASM的存储结构。使用ASM的RDBMS仍然是采用Tablespace、Segment、Extent这种结构来组织空间的，这与传统的RDBMS方式一样。

图5-2 ASM存储结构

所不同的是，RDBMS 的 Extent 不再是对应到 Data Block，而是对应到 ASM 的 AU （Allocation Unit）；另一点不同是，空间的分配不再是以Data File形式，而是ASM File，这一点也提示了一个 ASM Filesystem 的存在。总的来说数据库的 Extent 和 ASM 的 AU 有如下的关系。

ASM 磁盘被划分成一个个的AU（Allocation Unit），AU 是ASM 磁盘的最小存储单位（AU），一般每个AU是1MB。

数据库仍然使用Extent作为基本单位，Extent是RDBMS的内容，需要对应到ASM的AU；Extent和AU的对应关系一般是1:1，但如果使用了ASM的冗余功能，关系就变成1:2或1:3（叫做2-way或3-way mirroring）。

数据库仍然是利用Extent Map来操作数据。在传统的存储方式中，Extent Map是从数据文件中获得的；而在 ASM 环境下，这个 Extent Map 不是从数据文件获得，而是从 ASM实例获得。

数据库实例从ASM获得Extent Map后，后续的读写操作直接操作磁盘，而不再经过ASM实例。

5.1.2 条带化和镜像

条带化和镜像（Stripe and Mirror Everything，SAME）是最早的数据保护技术，现在已经广泛普及，甚至高级点的PC都配备这种功能，而企业级服务器通常来说都会配备硬件的RAID卡。因此，Oracle ASM 所提供的条带化和镜像用处并不太多，企业倾向于优先选择硬件而不是软件的解决方案。当然也不是那么绝对，而且Oracle ASM的条带、镜像的做法还有些特殊之处。我们接着往下看。

ASM的条带化是在ASM File级别配置的，可以配置成Fine和Coarse两种方式。

（1）粗粒度条带（Coarse Striping）。

这种条带化是在AU级别作的，每个AU默认大小1MB，假设磁盘组由4个磁盘组成，则数据文件的第1个Extent写到磁盘1的AU1中，第2个Extent会被写到磁盘2的AU1中，第3个Extent会被写到磁盘3的AU1中，第4个Extent会被写到磁盘4的AU1中，第5个extent写到磁盘1的AU2中，依次循环。

（2）细粒度条带（Fine Striping）。

这种条带化缺省是以128kB为单位进行的，也就是数据文件的第1个128kB被写到磁盘1的AU1中，第2个128kB被写到磁盘2的AU1中，依次循环。

之所以有两种条带化方法，主要是因为 Oracle 文件的区别。对于大部分 Oracle 文件（包括数据文件、归档日志、备份集），文件本身很大，每次IO操作的数据量也很大，比如1MB。对这些文件操作时，真正的磁盘数据读写时间远大于磁头的寻址时间，因此这种模式下，使用一个较大的条带策略（Coarse Striping）可以提高吞吐量。

而控制文件、联机日志文件，这些文件本身都很小，甚至都不到 1MB，或者每次 IO操作数据量很小，如果以 AU 为单位来分散文件内容，则磁头寻址时间在整个等待时延中相当可观，这时通过把数据分布到多个磁盘的 AU 上，通过并行的方式可以有效地减少这个时延。

具体到每个ASM文件是采用的哪种条带化策略，是由文件创建时使用的文件模板决定的，ASM会给每一类文件都配备一个缺省模板，所以如果我们没有指定模板，ASM就使用这个缺省模板。

5.1.3 镜像

Oracle ASM的SAME是在创建磁盘组时设定的。Normal Redundancy就意味着有一份备份（也可以叫冗余或者镜像）。因此，这种策略就需要至少两个ASM磁盘，一个数据会写两次，分别写到两个不同的磁盘上。High Redundancy 意味着三份镜像或者三路镜像。因此，磁盘组里至少要有 3 个磁盘，每个数据要写 3 遍，分别写到 3 个不同的磁盘上。如果是 External Redundancy，就是说底层的存储设备已经提供了数据镜像和条带功能，不需要Oracle操心了。这时，Oracle就只会记录一份数据，没有任何冗余了（这是我们最常见到的用法）。

ASM的手法和我们已经非常熟悉的硬RAID有很大不同，是在extent级别进行的。例如，假设一个磁盘组包括5块磁盘（编号1、2、3、4和5），我们使用了Normal Redundancy（两路镜像）策略。假设数据文件有10MB那么大，每个AU有1MB那么大，则数据的分布可能是这样的：第1个AU和它的镜像放在磁盘3、磁盘5上，第2个AU和它的镜像放在磁盘2、磁盘4上，第3个AU和它的镜像放在磁盘1、磁盘2上，凡此种种。也就是说，每个extent都会被镜像，但是没有两个磁盘是一样的。

ASM的条带也是同样的手法，因此，我们不能预知文件在磁盘上的分布。比如，我们的数据文件有 4GB，磁盘组中有 10个磁盘，我们不能说每个磁盘上有 1/10的数据分布，我们也不需要关心分布。Oracle的AM会自动地调整extent的分布，尽量寻找IO的平衡，避免出现热点块。如果发现某个磁盘有异常的 IO，就会使用位于不同磁盘上的镜像（如果有镜像的话），或者把 extent 移到其他负载不大的磁盘上去。本策略对所有文件都是如此，包括Redo Log。

1．Failure Group

如果不使用External Redundancy，而是使用ASM自己所提供的冗余机制来保证高可用性，就需要了解Parter Disk和Failure Group的概念。

每个ASM Disk Group都可以进一步拆分成Failure Group，如图5-3所示。每个ASM磁盘都会属于一个并且只属于一个Failure Group。

图5-3 Failure Group示意图

注意：一旦某个磁盘被分配到了一个Failure Group，就不能把它再分配到另一个Failure Group。要想重新分配，你必须先把它从当前所属的Failure Group中删除，然后才能添加到其他的Failure Group。

一个Failure Group是由多个ASM Disk组成的集合。这个集合有这样的特点——这个集合中的磁盘会因为同一个元素的问题导致不可用，这些元素包括以下几项：

同一个RAID控制卡；

同一个HBA卡；

同一个FC交换机；

磁盘；

盘柜。

由于RAC中使用的都是共享存储，主机上的某个进程比如LGWR发出IO调用到最后的磁盘IO，这条IO通道上其实是有很多元素参与活动的，包括上面这些元素。这个通道里的任何一个元素发生故障，都会导致这个通道失败。比如，如果一个RAID卡坏掉了，这个RAID卡上所有的磁盘就都无法访问了。如果数据和数据的镜像又都恰好在这些磁盘上，很显然数据就都无法使用了。因此，之前的那种冗余机制虽然可以解决单个磁盘损坏的风险，但是无法解决其他的风险。而Failure Group把这种风险控制又提高了一个级别。

有了Failure Group之后，我们可以把来自同一个控制器的磁盘都分配到一个Failure Group中，然后在两个Failure Group之间进行映像，如果是Normal Redundancy模式，每一个extent都会有一个primary copy和second copy，ASM的算法保证了second copy和primary copy一定是在不同的Failure Group中，这就是Failure Group的意义。通过这个算法，ASM保证了即使一个Failure Group中的所有disk都损坏了，数据也是毫发无伤的。

这是 Oracle 10g 的 ASM 就已经提供的功能，它是镜像功能的一个补充。要使用 Failure Group，必须要保证两个Failure Group不能共用一个故障点。

使用了 Oracle 的数据冗余功能后，Oracle 分配 extent 时在 ASM 这一端就不是分配一个extent 了，而是分配出自多个Failure Group 中的多个extent，当然这些extent 上的数据是完全一样的。所有Failure Group 中的这个拥有相同数据的extent就构成了一个extent set，这里面会有一个extent充当primary copy，其他的就是secondary copy了。当Oracle写数据时，primary copy可能在任何一个Failure Group 中，而secondary copy 则在另外的Failure Group 中，当Oracle读取数据的时候，除非是primary copy不可用，否则将优先从primary copy中读取数据，通过这种写入无序、读取有序的算法，Oracle保证了数据读取尽量分布在多个disk中。

Failure Group 是一个隐含的概念，即使我们创建磁盘组时没有显式指定，后台也是要创建Failure Group的。只是这时，每个磁盘自己是一个Failure Group，Group的名字就是磁盘的名字。也就是说，默认情况下，镜像是在磁盘之间进行的。

ASM磁盘组的冗余配置和Failure Group的数量没有任何联系，Normal Redundancy并不是说必须要有两个Failure Group（但是至少要有两个），High Redundancy也不是要有3个Failure Group（同样，至少要有3 个）。比如，下面这个例子就是用4 个Failure Group 创建的Normal Redundancy磁盘组。

SQL> CREATE DISKGROUP DATA_NRML NORMAL REDUNDANCY

FAILGROUP FLGRP1 DISK '/dev/rdsk/c3t19d3s4','/dev/rdsk/c3t19d4s4',

'/dev/rdsk/c3t19d5s4', '/dev/rdsk/c3t19d6s4'

FAILGROUP FLGRP2 DISK '/dev/rdsk/c4t20d3s4','/dev/rdsk/c4t20d4s4',

'/dev/rdsk/c4t20d5s4', '/dev/rdsk/c4t20d6s4'

FAILGROUP FLGRP3 DISK '/dev/rdsk/c5t21d3s4','/dev/rdsk/c5t21d4s4',

'/dev/rdsk/c5t21d5s4', '/dev/rdsk/c5t21d6s4'

FAILGROUP FLGRP4 DISK /dev/rdsk/c6t22d3s4','/dev/rdsk/c6t22d4s4',

'/dev/rdsk/c6t22d5s4', '/dev/rdsk/c6t22d6s4';

2．Partner Disk

ASM 的数据镜像功能是在所谓 Partner Disk 之间进行的。不过，ASM 的数据镜像和硬件镜像不一样，不是在磁盘级别进行的镜像，而是在extent级别进行的。要是硬件镜像，那数据盘和镜像盘肯定是一模一样的，只要这两个盘报废了，这些数据肯定就牺牲了。而ASM的镜像是在extent级别进行的，假设有3个extent，那这3个extent的镜像可能分别在3个ASM磁盘上。因此，ASM是没有所谓Primary Disk或者Mirror Disk的概念的。当ASM要在某个Failure Group的某个磁盘上分配一个primary extent时，就会在另一个Failure Group的某个磁盘上分配一个mirror copy extent（secondary extent），ASM会确保primary extent和它的mirror copy extent用于不会位于同一个Failure Group上。

在一个磁盘组中，一个磁盘最多可以有10个Partner Disk（也就是说，一个磁盘组中可以有超过10个Failure Group，但是具体到某个磁盘而言，它的Partner Disk最多分布在10个Failure Group 中）。这也就意味着，一个磁盘上的 extent 可以被镜像到这个磁盘的 10 个 Partner Disk中的任何一个上。这么做可以避免因为同时坏掉两个磁盘（这两个磁盘恰好是Partner Disk）而带来的数据丢失。

假设一个磁盘组有100块磁盘，如果extent的映射像硬件RAID那样只是在两块磁盘间发生，那么这两块磁盘坏了后就会造成数据的丢失。但是现在数据可以在 10 块磁盘间镜像，因此某块磁盘坏了后，只要它的10 块Partner Disk在线，数据就不会丢失，而其他的89 块磁盘中的任何一个损坏都不会影响数据。

在选择Partner Disk时，ASM是从其他的Failure Group中选择磁盘，而不会从这个磁盘所在的Failure Group中选择，可以用下面的语句查看某个ASM Disk的Partner Disk的所在，在这个例子中，查看的ASM Disk属于FLGRP1，但是它的10个Partner Disk全部来自于其他的Failure Group，这是一个Normal Redundancy的磁盘组。

SQL> SELECT NUMBER_KFDPARTNER, FAILGROUP

FROM X$KFDPARTNER A, V$ASM_DISK B

WHERE DISK=2 AND GRP=1

AND A.NUMBER_KFDPARTNER= B.DISK_NUMBER;

NUMBER_KFDPARTNER FAILGROUP；

----------------- ------------------------------

7　FLGRP2

8　FLGRP2

10　FLGRP2

12　FLGRP2

16　FLGRP3

17　FLGRP3

19 FLGRP3

24 FLGRP4

25 FLGRP4

26 FLGRP4

理解了Failure Group和Partner Disk之后，我们可以得到下面的结论。

（1）对于Normal Redundancy：

数据有两份镜像；

每个磁盘组至少要有两个Failure Group；

每次数据Extent都写到两个Failure Group 上；

一个primary extent加一个mirror extent等于一份extent set。

（2）对于High Redundancy：

数据有3份镜像；

每个磁盘组需要至少3个Failure Group；

每个数据extent写到3个Failure Group中；一个primary extent加2个mirror extent等于一份extent set。

理论上说，一个ASM实例最多可以支持到63个磁盘组，最多支持10000个磁盘，每个磁盘最大可以是 2TB 的空间。每个磁盘组可以最多到 1000000 个 ASM 文件，每个文件最大到128TB（RDBMS实例的数据文件最大只能到128TB），也就是ASM实例最大到20PB的容量。

这一节其实是回顾了Oracle 10g的ASM特性，只有打好基础，我们才能更好地理解Grid 11.2中出现的ASM新特性。

5.2 Oracle 11g的特性

Oracle 11g有11.1和11.2两个版本，ASM在这两版中的定位有所不同。在11.1版本中，ASM是数据库软件的一部分，而在11.2版本中，ASM和Clusterware整合在一起成为Grid，除此之外，两个版本都有一些新特性，具体如下。

Oracle 11.1这一版的ASM是属于数据库的功能，这一版的增强包括：

全新的ASM文档；

ASM Fast Mirror Resync；

ASM Preferred Mirror Read；

ASM Fast Rebalance；

ASM Disk Group兼容属性；

ASM的滚动升级；

SYSASM角色；

ASMCMD增强（可以备份恢复磁盘组的元数据）。

而Grid 11.2这一版的ASM从数据库中移出来，并入到Grid中，这一版的增强包括：

ASMCA（ASM配置助手）；

ADVM（ASM的动态卷管理器）；

ACFS（ASM的集群文件系统）；

ACFS快照；

ASM Intelligent Data Placement（智能数据摆放）；

ASMCMD命令的增强。

5.2.1 全新的 ASM 文档

在Oracle 11g中，ASM作为一个单独的产品从数据库中被剥离出来，并开始提供了专门的文档，比如Oracle Database Storage Administration Guid。

5.2.2 新的 SYSASM 角色

Oracle为ASM提供了新的角色SYSASM，这个角色是ASM实例的管理角色。这个角色可以启动、关闭实例等，不需要SYSDBA这个角色了，未来也将不再支持SYSDBA角色了。对于SYSASM的验证要求和SYSDBA是一样的。

5.2.3 ASM Disk Group Attribute

从Oracle 11g开始，DBA可以直接给磁盘组指定属性（而不再是通过模板的方式继承），其中一些属性在Oracle 10g中已经有了，有些是在Oracle 11g中出现的，11.2版本又提供了更多的属性。同时还提供了一个attribute子句，不论是create diskgroup还是alter diskgroup命令都可以使用这个子句来定义或者调整属性。本书我们会接触到的属性如表5-1所示。

表5-1 磁盘组的属性

来看几个例子，我们可以在创建磁盘组的同时就指定属性：

CREATE DISKGROUP dgroup4 EXTERNAL REDUNDANCY

DISK '/oracle/asmdata/asm_dgroup1_04.asm'

ATTRIBUTE 'compatible.asm' = '11.1';

也可以在创建磁盘组之后，再通过ALTER命令来修改属性：

ALTER DISKGROUP DG1 SET ATTRIBUTE 'compatible.asm'='11.1.0'

可以通过v$ASM_ATTRIBUTE视图查看每个属性值：

Select group_number, name, value

from v$asm_attribute

5.2.4 兼容性参数

由于Oracle是把ASM当作一个通用的存储解决方案来定位的，因此它需要最大程度的考虑兼容性问题。单就数据库而言，就需要考虑如何与现有版本（10 或 11）以及未来版本之间的兼容问题。

Oracle ASM 11g提供了兼容性的细粒度控制，对于兼容性我们应该这么考虑：ASM磁盘组的生命周期中是要和两种实例打交道的，一个是所谓的ASM实例，这种实例负责磁盘组的维护；另一种实例是RDBMS实例，这种实例是真正的ASM用户。于是兼容性要做的就是能够在其间左右逢源，一边是和要挂载磁盘组的ASM实例和平共处，一边是和要读写磁盘组的RDBMS实例共同开发。

目前Oracle提供了3个专门解决兼容性问题的属性：compitible.asm、compatibility.rdbms、compatibility.advm。最后一个兼容性是和 ASM 的卷管理器有关的，和数据库关系不大，随着未来功能的更加丰富，可能还会有别的参数出现。目前我们只关注前两个属性，第一个属性叫做Oracle Disk Group Compatibility，这个属性控制了ASM磁盘上保存的数据的格式。第二个参数叫做Oracle Database Compatibility，这个属性控制的是使用这个磁盘组的数据库实例的最低版本，会影响ASM实例和RDBMS实例间往来交互的信息格式。

光有这两个参数还不够，这两个参数还要和另外两个兼容性参数配合才行。这两个兼容性参数就是RDBMS实例和ASM实例的compatibility属性。这些兼容性的关系如图5-4所示。

图5-4 兼容性参数关系

磁盘组的compitible.asm属性，这个属性说明哪个版本的ASM软件可以挂载这个磁盘组；应该大于或者等于使用这个磁盘组的RDBMS实例的compatibility属性。也就是要保证数据库的版本小于或等于Grid的版本才行。

compatible.rdbms决定了哪些数据库（RDBMS）可以使用这个磁盘组。这些数据库的compatibility 参数必须要设置成等于或者高于这个值才行。如果集群中有一些低版本的数据库需要使用这个ASM的磁盘组，需要小心这个参数的影响。而且，如果使用ASMCA创建磁盘组，这个参数的默认值就是11.2，会阻止之前版本的数据库的使用。

如果要使用磁盘组创建卷，compatible.advm这个参数必须设成11.2。

磁盘组的 compitible.asm 还要大于等于磁盘组自己的 compatibility.rdbms 属性。这两个属性一旦被设置，是不可以向后调整的。

注意：一旦这些参数被设置成某个值，只能修改成更高的值，而不能反过来。如果要使用低版本，你只能创建一个新的磁盘组，然后通过移动或者恢复的方式把文件或者数据从旧的磁盘组移到新的磁盘组。

举例解释下这里的关系，假设 ASM 磁盘组的 compatible.asm 设置成 11.1，而磁盘组的compatible.rdbms设置成10.2，这就意味着只有版本在11.1以上的数据库才能管理这个磁盘组，不过版本在10.2以上的数据库都可以使用这个磁盘组来保存数据。

每个磁盘组都有它自己的兼容设置，因此，一个ASM实例可以有多个不同版本的Oracle数据库来使用它。

除了影响使用它的数据库，这些参数对 ASM 自己的功能也有影响，我们可以用disk_repair_time和compatible.asm的关系验证一下。如果没有调整过compatible.asm参数，那它的缺省值应该是10.1，试着修改下disk_repair_time参数值，会遇到以下这个错误：

ORA-15032: not all alterations performed

ORA-15242: could not set attribute DISK_REPAIR_TIME

ORA-15283: ASM operation requires compatible.rdbms of 11.1.0.0.0 or higher

这个消息表明，你应该把compatible.asm属性从缺省的10.1调整到11.1.0。因此，兼容性属性不仅控制访问ASM磁盘组的数据库，也会影响到可以使用的新特性。

ASM各种功能对3个兼容性参数的要求如表5-2所示。

表5-2 ASM特性和兼容性参数的关系

5.2.5 ASM Fast Disk Resync（Fast Mirror Resync）

通常情况下，如果一个磁盘发生了离线（Offline）了，ASM就会Drop掉这个磁盘。DBA解决了问题后，需要手动对整个磁盘组进行重构。重构是很耗费资源的操作，应该尽量避免或减少。是否能够减少呢？答案是肯定的。

我们知道，RAC环境用的是共享存储，通常都是光纤盘柜。从数据库主机到最终磁盘的访问通路叫做一个 IO 路径，这个路径上有很多元素的参与，包括主机上的驱动、光纤卡、光纤线、光纤交换机、盘柜上的SP、盘柜本身的IO环路，最终才到达磁盘。这条通路上的任何一个环节的问题都可能表现为磁盘Offline。某些时候错误可能是临时性的，因为盘柜本身就有冗余设计和管理单元，因此问题可能很快就会自动解决。如果ASM一点容错能力都没有，那这种重构的代价就有些太大了。

于是Oracle引入了这个新特性，启用了这个新特性后，当某个问题导致某个磁盘离线后（也就是这个Failure Group暂时不可用），ASM不会马上把这个磁盘Drop，而是要等待一定时间，等待这个问题的解决。这个过程中，会创建一个所谓的Staleness Registry来跟踪这个磁盘上的AU变化，当这个磁盘重新上线后，ASM使用这个Staleness Registry来恢复磁盘上的内容。也就是磁盘组的内容重新同步。重新同步所花费的时间长短取决于多种因素，不过通常要比重构整个磁盘组更快速。在重新同步的过程中，ASM 磁盘是完全可操作的，不过肯定会有一些性能上的损失。如果等待期间问题没有解决，也就是说等待超时了，这个磁盘就会被 Drop 掉，这时才会需要进行一次彻底的重构。这个特性和快速增量备份所使用的Block Change Tracking技术异曲同工。

要使用这个特性，需要设置磁盘组的disk_repair_time属性，设置了这个属性之后，resync进程就会跟踪并记录这些离线磁盘上的extent的更新操作，当这个磁盘重新在线后，resync进程就会把磁盘的内容重新同步，然后重新放回到磁盘组中。

这个参数值可以用分钟或者小时为单位进行定义（m/M 或者 h/H），也可以用分数定义非整小时（比如3.5H）。默认值是3.6小时。一旦磁盘被重新上线，时间就会被归零，也就是说，下次再离线后，这个值又从0开始计时。

如果磁盘离线，经过了定义的时间后还是没有被修复，那么这个磁盘就会被Drop。发生了offline之后，还剩下多少时间可以从V$asm_disk的repair_timer列获得。如果磁盘已经离线，我们想在超时之前把这个磁盘Drop掉，可以使用alter diskgroup …offline disk语句的drop after子句。如果磁盘已经离线，是不可以再调整disk_repair_time这个参数的。

这个特性是Oracle 11.1开始引入的，是和Failure Group一起使用的。因此相关的命令中会有Failure Group的内容。

设置超时时间，同时也是启用了这个特性：

alter diskgroup dg1 set attribute 'disk_repair_time'='18h'

手工把ASM磁盘offline：

alter diskgroup dg1

offline disks in failgroup fg1 drop after 5h

把磁盘online：

alter diskgroup dg1

online disks in failgroup fg1 power 2 wait

如果磁盘无法修复，干掉它：

alter diskgroup dg1

drop disks in failgroup fg1 force

5.2.6 ASM Preferred Mirror Read

这个特性是ASM镜像技术的一个扩展，先来回顾一下镜像的内容。

ASM 使用镜像技术提供数据冗余，即一个数据会有多份，多个 extent 会有相同的内容，其中会有一个是primary extent，其他的是mirror extent。如果某个ASM磁盘丢了，可以借助分散在其他磁盘上的mirror extent而不会丢失数据。ASM还会利用这些mirror extent在这个磁盘组的其他磁盘上重建丢失的 extent，这些重构操作会均匀地分散到磁盘组的其他剩余磁盘中，对于做了镜像的ASM extent，读取操作不是严重的问题。因为默认时ASM读取primary extent，当读取失败时，ASM才会从mirror extent读取。只有当没有一个mirror extent可用时，才会抛出错误，这些错误会被记录到ASM的alert.log中。

对于写操作就比较严重了。对于ASM客户端发出的写操作，至少要有一个extent成功写入后才算成功。如果能够写到其他extent copy上，ASM实例需要把包含primary extent的磁盘offline，对RDBMS实例来说写操作是成功的。如果没有一个copy能够写入，RDBMS实例就需要采取行动把这个数据文件offline。ASM实例收到来自于RDBMS实例的写错误消息后，需要检查是否要把这个ASM磁盘offline，或者把整个磁盘组offline。

Oracle 11.1提供了一个新的参数ASM_PREFERRED_READ_FAILUER_GROUPS，这个参数是一个Failuer Group列表，代表着优先读取的对象。意味着只要可能就优先从这些磁盘组中读取数据。这就是说，到了 Oracle 11g 后，我们可以控制先从 secondary extent 中读取数据，而不是传统的从 primary extent 中读取数据。不过，这个参数并不会影响写操作的逻辑。每当要写入一个数据块时，对于这个 extent set 的写操作是并行的。所有的写操作都完成后才算成功。

这个特性只有在 RAC 环境中可用。如果两个磁盘组有着天生的某种限制，比如一个是本地的磁盘、另一个来自于网络共享。那么设置这个组会有意义。这一点对远程的 RAC 环境特别有意义。

如果一个 RAC 环境中包括远程的磁盘镜像，比如一个节点在北京，另一个在上海，每个实例本地都连着一套存储，这两套存储可以做成两个Failure Group相互镜像，对于这两个实例来说，本地存储才是最优读取数据的地方。为了保证最优性能，每个实例应该优先从本地的存储中获取数据。

要使用这个特性，需要配置 asm_preferred_read_failure_groups 参数，参数值的格式是diskgroupname.failuregroupname，可以是多个磁盘组的列表，之间用逗号隔开即可。

asm_preferred_read_failure_groups=dgroup1.fdisk2, dgroup2.fdisk2

如果ASM不能从preferred disk failure group中读取数据，它会从其他Failure Group中读取数据。从v$ASM_DISK视图的PREFERRED_READ中可以看到优先的信息。

不过说实话，Oracle 的这套官方说法理论上是成立的，但实际上是否真的有远程 RAC 存在，我表示怀疑。而且退一步说，还有很多其他技术可以实现相同的需求，远程 RAC 看起来是其中最不靠谱的一个。

5.2.7 可变 extent 大小

我们知道，extent是RDBMS的存储概念。在Oracle 11g之前，extent的数量，尤其对于大型数据库来说，那是相当的高。因此，extent map也是相当的大，以至于shared pool都无法管理，或出现ORA-4031 Unable to allocate x bytes in shared pool之类的错误。为了解决这个问题，Oracle 10g中允许我们用一个隐含参数来定义AU大小，比如_asm_ausize=16777216，这定义了16MB的AU。默认AU大小是1MB（在Oracle 10g、11g都是这个值）。不过，就算是可以调整AU的大小，也不是一步到位的解决办法。除非你能预测到未来数据库会有多大。

而在Oracle 11g中，通过可变的extent size来解决这个问题。在Oracle 11g中，extent的大小和AU的大小不再是紧密耦合的了，一个extent可以跨越多个AU，而且随着数据库的增大，extent的大小也会增加。从而保证extent map能在一个可以管理的范围内并保证性能。

当我们创建一个ASM文件时，Oracle需要给这个文件分配一个初始空间以容纳数据，这个初始空间就叫做initial extent，ASM文件的initial extent是1个AU。随着数据不断地增加，初始extent会被装满，文件就必须要扩展增加更多的extent。过多的extent扩展动作本身也需要成本，会增加更多的extent元数据。而增加的extent的秘密如表5-3所示。

表5-3 extent的秘密

这个表是说，当数据文件中extent的数量在20000之下时，extent的大小和AU的大小是匹配的，一个对一个。当超过了20000个但没超过40000个时，extent就开始变大了，变成1个extent对4个AU，当extent数量超过40000个时，一个extent就对应着16个AU。这样一来，Oracle就把extent map 控制在一个尽可能小的范围内，避免出现无法管控的局面。有人甚至觉得可变Extent可以看做是Oracle 11g ASM中最重要的变化，因此可以见其意义。

另外，每个ASM文件的最大大小是取决于extent的，可变extent意味着可以提供更大的数据文件，在Oracle 10g中，一个使用external redundancy的ASM文件最大是35TB，而在Oracle 11g中，这个数字达到了128TB。

5.2.8 全新的 asmca 图形工具

在Oracle 11.2之前，ASM是没有自己的图形化管理工具的，而是嵌在DBCA中的。从11.2开始，DBCA 工具不再支持 ASM，而是发展出一个全新的图形工具──ASMCA（ASM 配置器）。ASMCA简化了ASM实例的创建和配置工作，以及对ASM磁盘组的管理，ASM最新的ADVM 和 ACFS 也集成在了这个工具中。此外，ASMCA 也支持静默（silent）方式。传统的asmcmd命令行工具能干什么，这个图形工具就能干什么，而且干得更多更好。

5.2.9 ASMCMD 命令的增强

ASMCMD是个命令行工具，在Oracle 10.2中就已经提供了。Oracle 11g又补充了更多的功能。最重要的应该算对 ASM 元数据的备份和恢复了。比如，md_bakup 命令可以对全部的ASM元数据或者ASM元数据的子集（取决于使用的选项）进行备份。对应的md_restore是用来恢复的。

ASMCMD 的备份和恢复的操作对象只是 ASM 的元数据，并不包括数据库的数据，这一点不要有误解。

5.2.10 支持集群文件

在Oracle 11.2中，集群文件（OCR和VotingFile）都可以放在ASM中了。原来的裸设备方式不再支持。

5.2.11 Fast Rebalancing

ASM允许我们在线地向磁盘组添加磁盘、去掉磁盘的操作，而不会影响磁盘组的可用性，也不会影响数据库的可用性。当然，这也是Oracle所宣称的永远可用的一个卖点。

每当有这种操作时，ASM就会发起一个rebalance的操作。rebalance操作只会影响少量的extent的重新分配，我们可以通过ASM_POWER_LIMIT参数来控制这个操作。缺省时，这个参数值是 1，也就是说只有一个子进程被唤起执行这个操作。如果设置成 0，就是暂时停止这个操作，比如延迟到午夜再执行。在Oracle 11.2之前，这个参数最多可以设置成11，而Oracle 11.2最大值是1024，Oracle根据这个数字会生成相应数量的子进程完成这个操作。

这个操作可以通过v$asm_operation视图监控，不管这个值如何设置，只会有一个ASM实例执行这个操作，而且每个实例一个时间只能进行一个rebalance操作。

5.2.12 智能数据摆放（Intelligent Data Placement IDP）

这是Oracle 11.2中的新特性，这个特性的出发点是这样的：我们知道磁盘是由若干个盘片组成，而每个盘片上又划了若干磁道。这些磁道其实是一组同心圆，磁盘转动时，对各个同心圆来说，角速度是一样的，但线速度是不一样的。越外圈的磁道的线速度越大。所以，可以说磁盘最外圈区域的访问速度是最快的，越向圆心移动，访问速度越小。

IDP利用的就是磁盘的这种地理信息，因为最外圈的磁道转动速度最快，而且外圈可以存放的数据也最多。因此，热点数据库可以放置在最外圈这部分区域，而比较少访问的数据（冷数据）就放在磁盘的最内圈。另外，那些访问模式相同或者相似的文件可以放得近一些，以减少延迟。

IDP根据这些原理允许我们把数据文件定义成“冷cold”或者“热hot”，ASM保证最经常使用的数据或者热点数据放到访问速度最快的磁盘区域。

IDP的前提是ASM先把磁盘自己划分成hot、cold区域（region）。如果ASM无法确定磁盘的物理（集合）特性，IDP就没什么用处了。因此，如果我们用的是盘柜上划LUN的方式，IDP是不适用的。

使用IDP的条件如下：

磁盘组的数据量超过了一定比例，比如25%；

数据文件的访问频率不同，或者说热度不同；

JBDO（just a bunch of disks）设备，而不是SAN的LIN。

5.3 小结

这一章的主题是ASM，这次我并没有把重点放在像ASM数据结构这样的技术细节上，而是着重介绍了ASM的变迁以及这一版中出现的那些新特性，这些特性的变化都是围绕着ASM的产品定位而展开的。