第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的產品定位而展開的。