溫馨提示×
您好，登錄后才能下訂單哦！
點(diǎn)擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
市場占有率
ASM自動存儲管理技術(shù)已經(jīng)面世10多個(gè)年頭，目前已經(jīng)廣泛使用于各個(gè)領(lǐng)域的數(shù)據(jù)庫存儲解決方案。 到2014年為止，ASM在RAC上的采用率接近60%，在單機(jī)環(huán)境中也超過了25%。
RAC集群環(huán)境中3種存儲解決方案： ASM、集群文件系統(tǒng)和裸設(shè)備； 雖然仍有部分用戶堅(jiān)持使用古老的裸設(shè)備，但隨著版本的升級，更多用戶開始采用ASM這種ORACLE提供的免費(fèi)解決方案。
在國內(nèi)使用ASM的場景一般均采用 External Redundancy(11gR2除了存放ocr/votedisk 的DG外)。 一般在10.2.0.5和11.2.0.2之后的版本上ASM，還是較為穩(wěn)定的。
下圖為部分在產(chǎn)品環(huán)境中使用ASM的國外知名企業(yè)：
ASM FILE
ORACLE RDBMS Kernel內(nèi)核與ASM在高層交互是基于ASM中存放的文件即ASM FILE。 這和ORACLE RDBMS去使用文件系統(tǒng)或其他邏輯卷的方式?jīng)]有什么區(qū)別。 ASM中可以存放 數(shù)據(jù)文件，日志文件，控制文件，歸檔日志等等，對于數(shù)據(jù)庫文件的存放基本和文件系統(tǒng)沒啥2樣。
一個(gè)ASM FILE的名字一般以一個(gè)”+”和DiskGroup名字開頭。 當(dāng)ORACLE RDBMS KERNEL內(nèi)核的文件I/O層碰到一個(gè)以”+”開頭的文件時(shí)，就會走到相關(guān)ASM的代碼層中 而不是調(diào)用依賴于操作系統(tǒng)的文件系統(tǒng)I/O。 僅僅在File I/O層面才會認(rèn)識到這是一個(gè)ASM 中的文件，而其上層的內(nèi)核代碼看來ASM FILE和OS FILE都是一樣的。
ASM對ROWID和SEGMENT等RDBMS元素沒有影響，不過是數(shù)據(jù)文件存放在ASM中，ASM并不會打破ORACLE數(shù)據(jù)庫中的這些經(jīng)典元素。
在一個(gè)ASM Diskgroup中僅僅允許存放已知的ORACLE文件類型。假設(shè)一個(gè)文件通過FTP拷貝到ASM Diskgroup中，則該文件的第一個(gè)塊將被檢驗(yàn)以便確認(rèn)其類型，以及收集其他信息來構(gòu)建這個(gè)文件的完整ASM文件名。 如果其文件頭無法被識別，則該文件在DiskGroup中的創(chuàng)建將會報(bào)錯(cuò)。
僅有以下的文件類型可以存放在ASM Diskgroup中：
ORACLE 的2進(jìn)制可執(zhí)行文件和ASCII文件，例如alert.log和其他trace文件，則不推薦也不能存放在ASM Diskgroup里。
File Blocks
所有被ASM所支持的文件類型仍以其file block作為讀和寫的基本單位。在ASM中的文件仍保持其原有的 Block Size 例如 Datafile 仍是 2k~32k(默認(rèn)8k)，ASM并不能影響這些東西。
值得一提的是在ASM FILE NUmber 1 的FILEDIR中記錄了每一種FILE TYPE對應(yīng)的BLOCK SIZE，例如：
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 256 ; 0x004: blk=256
kfbh.block.obj: 1 ; 0x008: file=1
kfbh.check: 567282485 ; 0x00c: 0x21d00b35
kfbh.fcn.base: 220023 ; 0x010: 0x00035b77
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfffdb.node.incarn: 838529807 ; 0x000: A=1 NUMM=0x18fd7987
kfffdb.node.frlist.number: 4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes: 20 ; 0x00c: 0x00000014
kfffdb.lobytes: 8192 ; 0x010: 0x00002000
kfffdb.xtntcnt: 35488 ; 0x014: 0x00008aa0
kfffdb.xtnteof: 35488 ; 0x018: 0x00008aa0 kfffdb.blkSize: 8192 ; 0x01c: 0x00002000 kfffdb.flags: 17 ; 0x020: O=1 S=0 S=0 D=0 C=1 I=0 R=0 A=0
kfffdb.fileType: 2 ; 0x021: 0x02
kfffdb.dXrs: 17 ; 0x022: SCHE=0x1 NUMB=0x1
kfffdb.iXrs: 17 ; 0x023: SCHE=0x1 NUMB=0x1
kfffdb.dXsiz[0]: 20000 ; 0x024: 0x00004e20
這里的kfffdb.blkSize即是 一個(gè)數(shù)據(jù)文件的Block Size。
由于這個(gè)blocksize 總是2的次方，所以一個(gè)block總是在 一個(gè)AU allocation Unit中，而不會跨2個(gè)AU。
Data Extents
數(shù)據(jù)盤區(qū)Data Extents 是裸的存儲，用以存放文件內(nèi)容。每一個(gè)Data Extent在 11g之前對應(yīng)某一個(gè)ASM disk上的一個(gè)Allocation Unit ， 在11g之后 一個(gè)Extent可以對應(yīng)多個(gè)AU，具體見《【Oracle ASM】Variable Extent Size 原理》。
Extent Map
Extent Map盤區(qū)圖是盤區(qū)指針的列表，這些指針將支出所有屬于一個(gè)文件的數(shù)據(jù)盤區(qū)。這些盤區(qū)是真正存放數(shù)據(jù)的裸存儲空間。每一個(gè)盤區(qū)指針給出其所在的磁盤號和AU信息。為了保證可信，每一個(gè)盤區(qū)指針也會包含一個(gè)checksum byte來確認(rèn)本指針未損壞。當(dāng)這個(gè)checksum值和實(shí)際存放的Extent信息不匹配時(shí)可能出現(xiàn)ORA-600錯(cuò)誤，例如ORA-00600: internal error code, arguments: [kffFdLoadXmap_86], [256], [0], [1], [68], [54], [29], [], [], [], [], []。
Virtual Data Extents
虛擬數(shù)據(jù)盤區(qū) Virtual Data Extent是幾個(gè)data extent的集合，這些data Extent中包含了相同的數(shù)據(jù)。 鏡像Mirror是在虛擬Extent級別實(shí)現(xiàn)的。每一個(gè)虛擬extent為文件塊提供一個(gè)盤區(qū)地址空間。每一個(gè)寫入到文件塊均是寫入到一個(gè)虛擬extent中每一個(gè)Online在線的data extent中。 每一個(gè)對文件塊的讀取也是被重定位到一個(gè)虛擬extent中的主鏡像extent (primary Extent)，除非primary extent所在Disk被OFFLINE了。 對于沒有冗余度(即external redundancy disk group上的FILE)的文件而言，一個(gè)虛擬Extent實(shí)際就是一個(gè)data Extent。
對于Normal redundancy+普通數(shù)據(jù)庫文件而言， 一個(gè)虛擬Extent實(shí)際就是2個(gè)Data Extent。
對于High redundancy+普通數(shù)據(jù)庫文件而言， 一個(gè)虛擬Extent實(shí)際就是3個(gè)Data Extent。
粗粒度條帶化Coarse Grain Striping
粗粒度條帶化就是對虛擬data Extent的簡單聯(lián)接。類似于傳統(tǒng)卷管理器使用1MB作為stripe size。
細(xì)粒度條帶化Fine Grain Striping
細(xì)粒度與粗粒度的區(qū)別在于，文件塊不是線性地布局在每一個(gè)虛擬Extent上，而是文件將以1/8個(gè)虛擬Extent成長，由此文件塊被在diskgroup內(nèi)以1/8的條帶化深度分布。 由此當(dāng)該文件的block size 為8k，則block 0~15在虛擬Virtual Extent 0上面，而block 16-31 在Vritual Extent 1上面，blocks 112-127在vritual extent 7， block 128-143在block 0-15之后仍在virtual extent 0上。
File Templates
File Template文件模板當(dāng)文件被創(chuàng)建時(shí)用以指定 條帶化 (coarse 或 FINE) 和冗余度(external, normal, high)。 ORACLE默認(rèn)已經(jīng)為每一個(gè)ORACLE數(shù)據(jù)庫文件提供了默認(rèn)模板?？梢孕薷哪J(rèn)模板 也可以客制化模板。修改模板只影響新創(chuàng)建的文件，而不是現(xiàn)有文件。 創(chuàng)建文件時(shí)可以指定使用某一個(gè)模板。
默認(rèn)的模板如下：
Failure Group
ASM提供冗余，failure group用來保證單點(diǎn)錯(cuò)誤不會造成同一數(shù)據(jù)的多份拷貝同時(shí)不可用。 如果ASM使用的多個(gè)ASM DISK LUN屬于同一硬件 例如同一磁盤陣列，該硬件故障會導(dǎo)致這多個(gè)盤均不可用，則該硬件的失敗應(yīng)當(dāng)被容錯(cuò)， 在ASM中一般將這些盤規(guī)劃到同一個(gè)failure group中。多份冗余拷貝不會存放在同一個(gè)failure group的磁盤中，換句話說一個(gè)failure group中只有一份數(shù)據(jù)的拷貝，不會有第二份。
由于Failure Group的配置很大程度上與用戶的本地規(guī)劃有關(guān)，所以ASM允許用戶自己指定Failure group的規(guī)劃、組成。 但是如果用戶自己沒有指定Failure Group的規(guī)劃，那么ASM會自動分配磁盤到必要的Failure Group。
使用External Redundancy的Diskgroup沒有Failure Group。Normal redundancy Disk Groups要求至少2個(gè)Failure Group，High Redundancy Disk Groups要求3個(gè)Failure Group。
如果Normal redundancy Disk Groups中有多于2個(gè)的Failure Group，例如 Failure Group A、B、C，則一個(gè)Virtual Extent會自動在A、B、C之間找2個(gè)Failure Group存放2個(gè)mirror extent，不會存放3份拷貝。
High Redundancy Disk Groups與之類似。
實(shí)際上，國內(nèi)對ASM的運(yùn)行，絕大多數(shù)不依賴于ASM實(shí)現(xiàn)redundancy，而是使用 External Redundancy的， 在Maclean遇到的場景中External Redundancy占了70%以上。
實(shí)際應(yīng)用中 Normal/High一般會和多個(gè)存儲控制器Controller 結(jié)合來分配failure group，或者存在多路存儲可用。
以下為一個(gè)示例， 一個(gè)normal redundancy 的Diskgroup 中存在8個(gè)Disk，并使用2個(gè)Failure Group：
當(dāng)磁盤Disk H失敗，這個(gè)失敗要求在失敗磁盤上所有的Extent均被修復(fù)， Extent 3和5會從現(xiàn)存的拷貝中復(fù)制到Failgroup 2 中可用的區(qū)域。在此例子中，Extent 5被從Disk A拷貝到Disk F，extent 3從Disk C 拷貝到Disk G，最后還會將失敗的磁盤從Diskgroup中drop出去。
Disk Partners
Disk Partnership是一種基于2個(gè)磁盤之間的對稱關(guān)系，存在于high 或 normal的redundancy diskgroup中。Diskgroup中的Disk與同一個(gè)Diskgroup內(nèi)的其他幾個(gè)disk組成結(jié)伴關(guān)系。ASM會自動創(chuàng)建和維護(hù)這種關(guān)系。鏡像拷貝數(shù)據(jù)僅僅在已經(jīng)與主數(shù)據(jù)鏡像primary data extent組成partners關(guān)系的磁盤上分配。
Disk partnering用來減少由于同時(shí)2個(gè)磁盤故障導(dǎo)致的數(shù)據(jù)丟失的概率。原因在于當(dāng)ASM配置中使用了較多的磁盤時(shí)(例如上千個(gè))，如果如果數(shù)據(jù)鏡像是隨機(jī)尋找次級磁盤來存放鏡像拷貝，當(dāng)2個(gè)磁盤丟失時(shí)有較大概率丟失數(shù)據(jù)。原因是如果采取隨機(jī)存放鏡像數(shù)據(jù)的話，出現(xiàn)數(shù)據(jù)的 primary和鏡像數(shù)據(jù)同時(shí)存在于2個(gè)正好失敗的磁盤上的概率是很高的。 如果我們不采取disk partnering，2個(gè)磁盤失敗所造成的數(shù)據(jù)丟失的概率大大增加。
Disk partnering策略限制了用來保護(hù)某個(gè)磁盤數(shù)據(jù)拷貝的磁盤數(shù)目。ASM為一個(gè)磁盤限制了disk partners的總數(shù)為8。 這個(gè)數(shù)目越小，則雙磁盤同時(shí)失敗造成數(shù)據(jù)丟失概率越小。 但是這個(gè)數(shù)目越小，也會造成其他不便。所以O(shè)RACLE ASM研發(fā)團(tuán)隊(duì)最終選擇了8這個(gè)數(shù)字。
ASM從本disk所在Failure group之外的FG 中挑選partners disk，由于一個(gè)ASM DISK有多個(gè)partners，所以其多個(gè)partners disk可能有的在同一個(gè)failure Group中。Partners被盡可能多的選擇在不同的Failure Group中，這樣做的目的也很明確，提高磁盤失敗時(shí)的容錯(cuò)能力。askmaclean.com
如果一個(gè)ASM DISK失敗了，其保護(hù)的extents可以通過其partners來重建。由于有多個(gè)partners所以其額外的I/O負(fù)載是在多個(gè)ASM disk中均衡損耗的。 這減少了修復(fù)故障的失敗時(shí)間，因?yàn)楦嗟拇疟P參與進(jìn)來，可以獲得更高的I/O吞吐量，所以加快了重構(gòu)丟失數(shù)據(jù)鏡像的速度。Partners被盡可能多的選擇在不同的Failure Group中，這樣做可以讓重建丟失磁盤的負(fù)載均勻分布在盡可能多的硬盤資源上。 以上這些考慮均是基于同時(shí)不會有2個(gè)failgroup同時(shí)失敗這個(gè)前提假設(shè)。
注意Partnering不是分區(qū)partitioning，Partnering僅僅是一種對稱關(guān)系。如果Disk A將Disk B列出partner，則相對地Disk B也將Disk A列為partner。 但是partnering不是一種臨時(shí)的關(guān)系。 同時(shí)假設(shè)disk A 和 Disk B是partners, 而Disk B和Disk C也是partners, 但這并不代表A和C是partners。
實(shí)際如果對partnering relationship有足夠的傳遞性則可能表現(xiàn)為分區(qū)，如下圖中的例子。但是分區(qū)僅僅是partnering可以提供的一種可能性。
partitioning分區(qū)僅僅是Partnering的特殊表現(xiàn)，Partnering本身已經(jīng)能夠保證在Disk磁盤以不規(guī)則的幾何安排方式組織時(shí)仍能同一負(fù)載均衡，其移除了當(dāng)額外的容量需要增加到現(xiàn)有系統(tǒng)時(shí)的許多限制。當(dāng)然這仍不能保證在所有配置下都很完美，但ASM會基于現(xiàn)有給定的配置采取最佳的方案。
下面為一個(gè)Partning的例子：
ASM mirror 保護(hù)
ASM mirror 鏡像保護(hù)可避免因丟失個(gè)別磁盤而丟失數(shù)據(jù)。每一個(gè)文件均有自己的ASM鏡像策略屬性， 對于該文件所轄的所有virtual extent來說同樣基于該鏡像策略。文件創(chuàng)建時(shí)會設(shè)置這個(gè)鏡像策略屬性，今后都無法修改。 ASM鏡像要比操作系統(tǒng)鏡像磁盤要來的靈活一些，至少它可以在文件級別指定需要的冗余度。
ASM mirror區(qū)分鏡像extent的primary和secondary拷貝，但在更新extent時(shí)會同時(shí)寫所有的拷貝鏡像。 ASM總是先嘗試讀取primary 拷貝，僅當(dāng)primary拷貝不可用時(shí)去讀取secondary拷貝。
ASM metadata
Asm Metadata是存在于ASM disk header用以存放ASM Diskgroup 控制信息的數(shù)據(jù)，Metadata包括了該磁盤組中有哪些磁盤，多少可用的空間，其中存放的File的名字，一個(gè)文件有哪些Extent等等信息。
由于Asm metadata就存放在ASM DISK HEADER，所以ASM disk group是自解釋的。所有的metadata元數(shù)據(jù)均存放在一個(gè)個(gè)metadata block中(默認(rèn)block size 4096)。這些信息包括該metadata block的類型以及其邏輯位置。同樣有checksum信息來確認(rèn)block是否被損壞。所有的metadata block均是4k大小。實(shí)際使用時(shí)ASM實(shí)例會緩存這些ASm metadata。askmaclean.com
ASM Instance
ASM instance的主要任務(wù)之一就是管理ASM metadata元數(shù)據(jù)； ASM Instance類似于ORACLE RDBMS INSTANCE 有其SGA和大多數(shù)主要后臺進(jìn)程。在10.2中使用與RDBMS一樣的2進(jìn)制軟件，到11.2中分家。但ASM instance加載的不是數(shù)據(jù)庫，而是Disk Group; 并負(fù)責(zé)告訴RDBMS database instance必要的ASM 文件信息。 ASM實(shí)例和DB實(shí)例均需要訪問ASM DISK。 ASM實(shí)例管理metadata元數(shù)據(jù)，這些元數(shù)據(jù)信息足以描述ASM 中的FILE的信息。 數(shù)據(jù)庫實(shí)例仍舊直接訪問文件，雖然它需要通過ASM實(shí)例來獲得例如 文件Extent Map 盤區(qū)圖等信息，但I(xiàn)/O仍由其自行完成，而不是說使用了ASM之后DB的文件I/O需要通過ASM來實(shí)現(xiàn)； 其僅僅是與ASM instance交互來獲得文件位置、狀態(tài)等信息。
有一些操作需要ASM實(shí)例介入處理，例如DB實(shí)例需要創(chuàng)建一個(gè)數(shù)據(jù)文件，則數(shù)據(jù)庫服務(wù)進(jìn)程直接連接到ASM實(shí)例來實(shí)現(xiàn)一些操作； 每一個(gè)數(shù)據(jù)庫維護(hù)一個(gè)連接池到其ASM實(shí)例，來避免文件操作導(dǎo)致的反復(fù)連接。
ASM metadata通過一個(gè)獨(dú)立的ASM實(shí)例來管理以便減少其被損壞的可能。ASM instance很相似于db instance，雖然它一般只使用ORACLE KERNEL內(nèi)核的一小部分代碼，則其遇到bug或?qū)е耣uffer cache訛誤或者寫出訛誤到磁盤的概率由此比DB實(shí)例要小。 數(shù)據(jù)庫實(shí)例自己從來不更新ASM metadata。ASM metadata中每一個(gè)指針一般都有check byte以便驗(yàn)證。
和DB RAC一樣，ASM instance 自己可以被集群化，一樣是使用ORACLE Distributed Lock Manager(DLM)分布式鎖管理器架構(gòu)。在一個(gè)集群中每一個(gè)節(jié)點(diǎn)上可以有一個(gè)ASM instance。如果一個(gè)節(jié)點(diǎn)上有多個(gè)數(shù)據(jù)庫、多個(gè)實(shí)例，則他們共享使用一個(gè)ASM instance 。
如果一個(gè)節(jié)點(diǎn)上的ASM instance失敗了，則所有使用該ASM instance 均會失敗。但其他節(jié)點(diǎn)上的ASM和數(shù)據(jù)庫實(shí)例將做recover并繼續(xù)操作。
Disk Discovery
Disk Discovery磁盤發(fā)現(xiàn)是指從OS層面找到那些ASM值得訪問的磁盤。也用來找到那些需要被mount的diskgroup名下的磁盤ASM DISK，以及管理員希望將其加入到diskgroup中的Disk，或管理員會考慮將其加入到diskgroup的Disk。Discovery 使用一個(gè)discovery string( asm_diskstring)作為輸入?yún)?shù)，并返回一系列可能的DISK。注意一個(gè)是要指定asm_diskstring，另一個(gè)是要求這些disk的權(quán)限可以被oracle/grid用戶使用。精確的asm_diskstring discovery語法取決于操作系統(tǒng)平臺和ASMLIB庫。OS可接受的路徑名生成的匹配，一般對于discovery strings也是可用的。一般推薦這個(gè)路徑名下最好只有ASM Disk，來避免管理上的問題。
ASM實(shí)例會打開和讀取由asm_diskstring指定的路徑名匹配到的每一個(gè)文件并讀取前4k的block， 這樣做的目的是判斷disk header的狀態(tài)；如果它發(fā)現(xiàn)這是一個(gè)ASM disk header則會認(rèn)為這是一個(gè)可以mount的diskgroup的一部分。如果發(fā)現(xiàn)這4k的block其無法識別，則認(rèn)為該disk可以加入到ASM diskgroup中(candidate)。
ASM實(shí)例需要通過一個(gè)初始化參數(shù)來指定這個(gè)discovery strings，實(shí)際就是asm_diskstring； 注意 asm_diskstring中可以加入多個(gè)路徑字符串，例如 ‘/dev/raw*’,’/dev/asm-disk*’ ; 同樣的磁盤不會被發(fā)現(xiàn)2次(除非你欺騙ASM)。 在RAC cluster中如果一個(gè)磁盤不是在整個(gè)cluster范圍內(nèi)都可見，那么這個(gè)磁盤無法被加入到RAC的ASM DISKGROUP 中。 在實(shí)際使用中每一個(gè)節(jié)點(diǎn)上的磁盤名字可以不一樣，但其實(shí)際介質(zhì)要被操作系統(tǒng)識別，但是實(shí)際MACLEAN也強(qiáng)烈建議你保持每個(gè)節(jié)點(diǎn)上磁盤的名字一樣，否則管理很麻煩。 所以這里引入U(xiǎn)DEV等規(guī)則是有必要的。
Disk Group Mount 加載磁盤組
在數(shù)據(jù)庫實(shí)例可以用Diskgroup上的文件之前，需要ASM實(shí)例去 mount 這個(gè)本地diskgroup。 Mount Diskgroup牽扯到發(fā)現(xiàn)所有的磁盤并找到上面已經(jīng)有metadata數(shù)據(jù)的disk，并嘗試將對應(yīng)到一個(gè)diskgroup的DISK mount起來。 能 mount起來的前提還需要驗(yàn)證metadata來確?，F(xiàn)在已經(jīng)有足夠數(shù)量的磁盤在哪里，例如使用3個(gè)DISK創(chuàng)建的external diskgroup ，當(dāng)前OS下面只掛了2個(gè)Disk，則顯然不能mount這個(gè)diskgroup。 之后還需要初始化SGA以便之后更新和管理這些metadata。
可以顯示地去dismount一個(gè)diskgroup，但是如果diskgroup上的文件正在被client (例如DB)使用則dismount會報(bào)錯(cuò)。如果在ASM冗余算法容錯(cuò)能力內(nèi)丟失磁盤，則不會導(dǎo)致diskgroup被強(qiáng)制dismount。但是如果超出了容錯(cuò)能力則會被強(qiáng)制dismount。 這種強(qiáng)制dismount會導(dǎo)致使用其上文件的DB instance被kill。
Disk ADD 增加磁盤
加入一個(gè)磁盤到現(xiàn)有的Diskgroup 來擴(kuò)空間和增加吞吐量是很常見的需求。最簡單的加入磁盤命令如 : alter diskgroup Data add disk ‘/dev/asm-disk5’; 如前文所述在RAC cluster中如果一個(gè)磁盤不是在整個(gè)cluster范圍內(nèi)都可見，那么這個(gè)磁盤無法被加入到RAC的ASM DISKGROUP 中。
如果add disk指定的磁盤的disk header發(fā)現(xiàn)了其他diskgroup的信息或者操作系統(tǒng)的一些信息，則需要alter diskgroup Data add disk ‘/dev/asm-disk5’ force ; 加入FORCE選項(xiàng)。實(shí)際使用中盡可能避免使用FORCE選項(xiàng)。
需要注意的事add disk命令返回后只代表disk header已經(jīng)完成必要的metadata寫入，但不代表該磁盤已經(jīng)完成了rebalance操作。后續(xù)的rebalance會被引發(fā)并移動數(shù)據(jù)到新加入的磁盤中。一般推薦如果你要加入多個(gè)ASM DISK，那么在同一時(shí)間加入，而不是分多次加入。 但是一般不推薦同時(shí)做add disk和drop disk。
Disk Drop踢盤
可以從現(xiàn)有的Diskgroup里drop出disk，這些disk可以用作它途；當(dāng)然由于asm disk失敗，導(dǎo)致ASM實(shí)例自動drop 該失敗的asm disk也是常見的。若一個(gè)ASM DISK常發(fā)生一些非致命的錯(cuò)誤，則一般推薦將該Disk drop出來，以避免如果某天發(fā)生真的磁盤失敗導(dǎo)致可能的數(shù)據(jù)丟失。 但是需要注意drop disk時(shí) 不要指定其路徑名，而是指定ASM DISK NAME。
drop disk命令可能較短時(shí)間內(nèi)返回，但是diskgroup必須完成rebalance后這個(gè)磁盤才能被挪作他用。rebalance將讀取即將被drop掉disk的數(shù)據(jù)，并拷貝這些數(shù)據(jù)到其他磁盤上。FORCE選項(xiàng)可以用于避免讀取該正被drop的磁盤。該FORCE選項(xiàng)當(dāng)磁盤發(fā)生失敗或磁盤確實(shí)需要立即被挪用。原來那些需要被拷貝的extent，使用FORCE選項(xiàng)后會從冗余的備份中讀取，所以external redundancy不支持使用FORCE選項(xiàng)。當(dāng)然如果使用FORCE選項(xiàng)最后會導(dǎo)致在NORMAL/HIGH冗余的Diskgroup下造成數(shù)據(jù)丟失的話，則FORCE選項(xiàng)也將不可用。
DROP DISK NOFORCE:
DROP DISK FORCE:
對磁盤的寫入如果發(fā)生了嚴(yán)重的錯(cuò)誤那么也會導(dǎo)致ASM自動強(qiáng)制去DROP該Disk。如果該disk的drop會造成數(shù)據(jù)丟失，那么diskgroup被強(qiáng)制dismount，該dismount也會造成數(shù)據(jù)庫實(shí)例被kill。
Rebalance
rebalance diskgroup將在diskgroup范圍內(nèi)將數(shù)據(jù)在其DISK上移動，以保證文件們均勻分布在diskgroup中的所有磁盤上，同時(shí)也會考慮到每一個(gè)ASM DISK的大小。 當(dāng)文件均勻地分布在所有磁盤上，則各個(gè)磁盤的使用量也會很接近。如此以保證負(fù)載均衡。rebalance的算法既不基于I/O統(tǒng)計(jì)信息也不基于其他統(tǒng)計(jì)結(jié)果； 完全取決于Diskgroup中disk的大小。
一旦diskgroup中發(fā)生了一些存儲配置變化 例如disk add/drop/resize均會自動觸發(fā)一次rebalance。power參數(shù)將決定有多少slave進(jìn)程并發(fā)參數(shù)數(shù)據(jù)移動。所有的slave進(jìn)程均從發(fā)生rebalance的實(shí)力啟動并工作。rebalance可以手動調(diào)控，即便已經(jīng)在進(jìn)行一次rebalance中了，也可以指定其他節(jié)點(diǎn)上的實(shí)例做rebalance，只要管路員想要這樣做。如果實(shí)例意外crash，那么未結(jié)束的rebalance將自動重新啟動。
注意rebalance中的每一次extent 移動均會與數(shù)據(jù)庫實(shí)例做協(xié)調(diào)，因?yàn)閿?shù)據(jù)庫實(shí)例可能同時(shí)需要讀取或者寫這個(gè) extent，所以數(shù)據(jù)庫在rebalance 同時(shí)能正常工作。 其對數(shù)據(jù)庫的影響一般較小，原因是同一時(shí)間只有一個(gè)extent被鎖定以便移動，且僅僅是阻塞寫入。
ASMLIB
ASMLIB是通過在Linux上安裝asmlib包來提供標(biāo)準(zhǔn)I/O接口，以便ASM發(fā)現(xiàn)和訪問ASM disk。 關(guān)于ASMLIB詳見：
關(guān)于udev與asmlib 以及Multipath的問題，提問前先看這個(gè)
Disk Header
一個(gè)ASM DISK的最前面4096字節(jié)為disk header，對于ASM而言是block 0 (blkn=0)；許多操作系統(tǒng)會保留LUN的第一個(gè)block來存放分區(qū)表或其他OS信息。 一般不讓ASM基礎(chǔ)到這個(gè)block，因?yàn)锳SM會毫不猶豫地覆蓋這個(gè)block。在一些指定的平臺上ORACLE從代碼層跳過這些操作系統(tǒng)塊，但實(shí)際操作時(shí)一般的慣例是只給ASM用那些上面沒有分區(qū)表的LUN DISK。
對于這一點(diǎn)詳細(xì)的展開是，例如你在AIX操作系統(tǒng)上使用PV作為ASM DISK，則PV上不能有PVID，同時(shí)如果一個(gè)PV已經(jīng)分給ASM用了，但是由于系統(tǒng)管理員的疏忽而給PV分配了一個(gè)PVID，則該P(yáng)V 頭部的ASM disk header會被覆蓋掉，這將直接導(dǎo)致disk header丟失；如果是External Redundancy那么這個(gè)diskgroup就直接mount不起來了。所以對那些會影響ASM disk header的操作要慎之又慎，同時(shí)最好定期備份disk header。
ASM disk header描述了該ASM disk和diskgroup的屬性，通過對現(xiàn)有disk header的加載，ASM實(shí)例可以知道這個(gè)diskgroup的整體信息。
下面是一個(gè)典型的disk header的一部分, 其disk number為0 ，redundancy為KFDGTP_HIGH，diskname為DATA1_0000，diskgroup name 為DATA1，failgroup name為DATA1_0000：
kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 0 ; 0x004: blk=0 kfbh.block.obj: 2147483648 ; 0x008: disk=0 kfbh.check: 3107059325 ; 0x00c: 0xb931f67d kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfdhdb.driver.provstr: ORCLDISK ; 0x000: length=8 kfdhdb.driver.reserved[0]: 0 ; 0x008: 0x00000000 kfdhdb.driver.reserved[1]: 0 ; 0x00c: 0x00000000 kfdhdb.driver.reserved[2]: 0 ; 0x010: 0x00000000 kfdhdb.driver.reserved[3]: 0 ; 0x014: 0x00000000 kfdhdb.driver.reserved[4]: 0 ; 0x018: 0x00000000 kfdhdb.driver.reserved[5]: 0 ; 0x01c: 0x00000000 kfdhdb.compat: 186646528 ; 0x020: 0x0b200000 kfdhdb.dsknum: 0 ; 0x024: 0x0000 kfdhdb.grptyp: 3 ; 0x026: KFDGTP_HIGH kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER kfdhdb.dskname: DATA1_0000 ; 0x028: length=10 kfdhdb.grpname: DATA1 ; 0x048: length=5 kfdhdb.fgname: DATA1_0000 ; 0x068: length=10 kfdhdb.capname: ; 0x088: length=0 kfdhdb.crestmp.hi: 32999670 ; 0x0a8: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7de kfdhdb.crestmp.lo: 1788720128 ; 0x0ac: USEC=0x0 MSEC=0x36d SECS=0x29 MINS=0x1a kfdhdb.mntstmp.hi: 32999670 ; 0x0b0: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7de kfdhdb.mntstmp.lo: 1812990976 ; 0x0b4: USEC=0x0 MSEC=0x3 SECS=0x1 MINS=0x1b kfdhdb.secsize: 512 ; 0x0b8: 0x0200 kfdhdb.blksize: 4096 ; 0x0ba: 0x1000 kfdhdb.ausize: 4194304 ; 0x0bc: 0x00400000 kfdhdb.mfact: 454272 ; 0x0c0: 0x0006ee80 kfdhdb.dsksize: 32375 ; 0x0c4: 0x00007e77 kfdhdb.pmcnt: 2 ; 0x0c8: 0x00000002 kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001 kfdhdb.altlocn: 2 ; 0x0d0: 0x00000002 kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002 kfdhdb.redomirrors[0]: 0 ; 0x0d8: 0x0000 kfdhdb.redomirrors[1]: 0 ; 0x0da: 0x0000 kfdhdb.redomirrors[2]: 0 ; 0x0dc: 0x0000 kfdhdb.redomirrors[3]: 0 ; 0x0de: 0x0000 kfdhdb.dbcompat: 186646528 ; 0x0e0: 0x0b200000 kfdhdb.grpstmp.hi: 32999670 ; 0x0e4: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7de kfdhdb.grpstmp.lo: 1783335936 ; 0x0e8: USEC=0x0 MSEC=0x2e3 SECS=0x24 MINS=0x1a kfdhdb.vfstart: 0 ; 0x0ec: 0x00000000 kfdhdb.vfend: 0 ; 0x0f0: 0x00000000 kfdhdb.spfile: 0 ; 0x0f4: 0x00000000 kfdhdb.spfflg: 0 ; 0x0f8: 0x00000000 kfdhdb.ub4spare[0]: 0 ; 0x0fc: 0x00000000 kfdhdb.ub4spare[1]: 0 ; 0x100: 0x00000000 kfdhdb.ub4spare[2]: 0 ; 0x104: 0x00000000 kfdhdb.ub4spare[3]: 0 ; 0x108: 0x00000000
下面的信息是在同一個(gè)diskgroup中的所有disk的header上均會復(fù)制一份的：
下面的信息是每一個(gè)asm disk獨(dú)有的：
Freespace Table
AU=0 的blkn=1 包含的是free space table；其中包含了該AU中allocation table中每一個(gè)block上大致的可用剩余FREE SPACE可用空間信息。通過參考free space table可以避免在已經(jīng)分配完的allocation table中查找空間。
[oracle@mlab2 dbs]$ kfed read /oracleasm/asm-disk01 blkn=1 aun=0 aus=4194304|less
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 2 ; 0x002: KFBTYP_FREESPC kfbh.datfmt: 2 ; 0x003: 0x02
kfbh.block.blk: 1 ; 0x004: blk=1
kfbh.block.obj: 2147483648 ; 0x008: disk=0
kfbh.check: 3847932395 ; 0x00c: 0xe55ac9eb
kfbh.fcn.base: 22557 ; 0x010: 0x0000581d
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdfsb.aunum: 0 ; 0x000: 0x00000000
kfdfsb.max: 1014 ; 0x004: 0x03f6
kfdfsb.cnt: 73 ; 0x006: 0x0049
kfdfsb.bound: 0 ; 0x008: 0x0000
kfdfsb.flag: 1 ; 0x00a: B=1
kfdfsb.ub1spare: 0 ; 0x00b: 0x00
kfdfsb.spare[0]: 0 ; 0x00c: 0x00000000
kfdfsb.spare[1]: 0 ; 0x010: 0x00000000
kfdfsb.spare[2]: 0 ; 0x014: 0x00000000
kfdfse[0].fse: 0 ; 0x018: FREE=0x0 FRAG=0x0
kfdfse[1].fse: 0 ; 0x019: FREE=0x0 FRAG=0x0
kfdfse[2].fse: 0 ; 0x01a: FREE=0x0 FRAG=0x0
kfdfse[3].fse: 0 ; 0x01b: FREE=0x0 FRAG=0x0
kfdfse[4].fse: 0 ; 0x01c: FREE=0x0 FRAG=0x0
kfdfse[5].fse: 0 ; 0x01d: FREE=0x0 FRAG=0x0
kfdfse[6].fse: 0 ; 0x01e: FREE=0x0 FRAG=0x0
kfdfse[7].fse: 0 ; 0x01f: FREE=0x0 FRAG=0x0
kfdfse[8].fse: 0 ; 0x020: FREE=0x0 FRAG=0x0
kfdfse[9].fse: 0 ; 0x021: FREE=0x0 FRAG=0x0
kfdfse[10].fse: 0 ; 0x022: FREE=0x0 FRAG=0x0
kfdfse[11].fse: 119 ; 0x023: FREE=0x7 FRAG=0x7
kfdfse[12].fse: 16 ; 0x024: FREE=0x0 FRAG=0x1
kfdfse[13].fse: 16 ; 0x025: FREE=0x0 FRAG=0x1
kfdfse[14].fse: 16 ; 0x026: FREE=0x0 FRAG=0x1
kfdfse[15].fse: 16 ; 0x027: FREE=0x0 FRAG=0x1
kfdfse[16].fse: 16 ; 0x028: FREE=0x0 FRAG=0x1
kfdfse[17].fse: 16 ; 0x029: FREE=0x0 FRAG=0x1
kfdfse[18].fse: 16 ; 0x02a: FREE=0x0 FRAG=0x1
kfdfse[19].fse: 16 ; 0x02b: FREE=0x0 FRAG=0x1
kfdfse[20].fse: 16 ; 0x02c: FREE=0x0 FRAG=0x1
kfdfse[21].fse: 16 ; 0x02d: FREE=0x0 FRAG=0x1
kfdfse[22].fse: 16 ; 0x02e: FREE=0x0 FRAG=0x1
kfdfse[23].fse: 16 ; 0x02f: FREE=0x0 FRAG=0x1
kfdfse[24].fse: 16 ; 0x030: FREE=0x0 FRAG=0x1
kfdfse[25].fse: 16 ; 0x031: FREE=0x0 FRAG=0x1
kfdfse[26].fse: 16 ; 0x032: FREE=0x0 FRAG=0x1
kfdfse[27].fse: 16 ; 0x033: FREE=0x0 FRAG=0x1
kfdfse[28].fse: 16 ; 0x034: FREE=0x0 FRAG=0x1
aunum_kfdfsb First AU of first ATB of this FSB
max_kfdfsb Max number of FSEs per FSB
cnt_kfdfsb Number of FSEs up to end of disk
spare_kfdfsb spares for future
kfdfse – Kernel Files Disk Free Space Entry.
max_kfdfsb describes the number of free space entries which would
be used in this free space table if the disk were large enough to
provide all of the AUs which can be described by a single physical
metadata AU. cnt_kfdfsb describes the number of free space entries
which correspond to AUs which are actually present on the disk. In
the case where there are additional physical metadata AUs beyond the
one containing this kfdfsb, then max_kfdfsb will equal cnt_kfdfsb.
There are complications with the interpretation of cnt_kfdfsb when
a disk is being grown or shrunk. It is possible in these cases to
have allocated AUs past the range indicated by cnt_kfdfsb which have
not yet been relocated into the new area of the disk.
The Free Space Table provides a summary of which allocation table
blocks have free space. There is one kfdfse in the FST for each
Allocation Table block described by the FST.
The first key parameter is the stripe width of the array. Stripe width refers to the number of parallel stripes that can be written to or read from simultaneously. This is of course equal to the number of disks in the array. So a four-disk striped array would have a stripe width of four.
Allocation Table
Aun=0的后254個(gè)metadata block用以存放AU分配信息。 每一個(gè)metadata描述448個(gè)AU的狀態(tài)， 如果一個(gè)AU已經(jīng)分配給一個(gè)文件，則allocation table 記錄其ASM文件號和data extent號。對于還是FREE的AU則被link到free list上。
kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL kfbh.datfmt: 2 ; 0x003: 0x02 kfbh.block.blk: 2 ; 0x004: blk=2 kfbh.block.obj: 2147483648 ; 0x008: disk=0 kfbh.check: 2376540464 ; 0x00c: 0x8da72130 kfbh.fcn.base: 44495 ; 0x010: 0x0000adcf kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfdatb.aunum: 0 ; 0x000: 0x00000000 kfdatb.shrink: 448 ; 0x004: 0x01c0 kfdatb.ub2pad: 0 ; 0x006: 0x0000 kfdatb.auinfo[0].link.next: 112 ; 0x008: 0x0070 kfdatb.auinfo[0].link.prev: 112 ; 0x00a: 0x0070 kfdatb.auinfo[1].link.next: 120 ; 0x00c: 0x0078 kfdatb.auinfo[1].link.prev: 120 ; 0x00e: 0x0078 kfdatb.auinfo[2].link.next: 136 ; 0x010: 0x0088 kfdatb.auinfo[2].link.prev: 136 ; 0x012: 0x0088 kfdatb.auinfo[3].link.next: 20 ; 0x014: 0x0014 kfdatb.auinfo[3].link.prev: 20 ; 0x016: 0x0014 kfdatb.auinfo[4].link.next: 168 ; 0x018: 0x00a8 kfdatb.auinfo[4].link.prev: 168 ; 0x01a: 0x00a8 kfdatb.auinfo[5].link.next: 296 ; 0x01c: 0x0128 kfdatb.auinfo[5].link.prev: 296 ; 0x01e: 0x0128 kfdatb.auinfo[6].link.next: 552 ; 0x020: 0x0228 kfdatb.auinfo[6].link.prev: 3112 ; 0x022: 0x0c28 kfdatb.spare: 0 ; 0x024: 0x00000000 kfdate[0].discriminator: 1 ; 0x028: 0x00000001 kfdate[0].allo.lo: 0 ; 0x028: XNUM=0x0 kfdate[0].allo.hi: 8388608 ; 0x02c: V=1 I=0 H=0 FNUM=0x0 kfdate[1].discriminator: 1 ; 0x030: 0x00000001 kfdate[1].allo.lo: 0 ; 0x030: XNUM=0x0 kfdate[1].allo.hi: 8388608 ; 0x034: V=1 I=0 H=0 FNUM=0x0 kfdate[2].discriminator: 1 ; 0x038: 0x00000001 kfdate[2].allo.lo: 0 ; 0x038: XNUM=0x0 kfdate[2].allo.hi: 8388609 ; 0x03c: V=1 I=0 H=0 FNUM=0x1 kfdate[3].discriminator: 1 ; 0x040: 0x00000001 kfdate[3].allo.lo: 8 ; 0x040: XNUM=0x8 kfdate[3].allo.hi: 8388611 ; 0x044: V=1 I=0 H=0 FNUM=0x3 kfdate[4].discriminator: 1 ; 0x048: 0x00000001 kfdate[4].allo.lo: 19 ; 0x048: XNUM=0x13 kfdate[4].allo.hi: 8388611 ; 0x04c: V=1 I=0 H=0 FNUM=0x3 kfdate[5].discriminator: 1 ; 0x050: 0x00000001 kfdate[5].allo.lo: 29 ; 0x050: XNUM=0x1d kfdate[5].allo.hi: 8388611 ; 0x054: V=1 I=0 H=0 FNUM=0x3 kfdate[6].discriminator: 1 ; 0x058: 0x00000001 kfdate[6].allo.lo: 30 ; 0x058: XNUM=0x1e kfdate[6].allo.hi: 8388611 ; 0x05c: V=1 I=0 H=0 FNUM=0x3 kfdate[7].discriminator: 1 ; 0x060: 0x00000001 kfdate[7].allo.lo: 0 ; 0x060: XNUM=0x0 kfdate[7].allo.hi: 8388612 ; 0x064: V=1 I=0 H=0 FNUM=0x4 kfdate[8].discriminator: 1 ; 0x068: 0x00000001
Partner and Status Table
一般來說aun=1 是保留給Partner and Status Table(PST)的拷貝使用的。 一般5個(gè)ASM DISK將包含一份PST拷貝。多數(shù)的PST內(nèi)容必須相同且驗(yàn)證有效。否則無法判斷哪些ASM DISK實(shí)際擁有相關(guān)數(shù)據(jù)。
在 PST中每一條記錄對應(yīng)Diskgroup中的一個(gè)ASM DISK。每一條記錄會對一個(gè)ASM disk枚舉其partners的ASM DISK。同時(shí)會有一個(gè)flag來表示該DISK是否是ONLINE可讀寫的。這些信息對recovery是否能做很重要。
PST表的Blkn=0是PST的header，存放了如下的信息：
PST的最后一個(gè)塊是heartbeat block，當(dāng)diskgroup mount時(shí)其每3秒心跳更新一次。
以下為PST header
kfed read /oracleasm/asm-disk01 aun=1 blkn=0 aus=4194304 |less kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 17 ; 0x002: KFBTYP_PST_META kfbh.datfmt: 2 ; 0x003: 0x02 kfbh.block.blk: 1024 ; 0x004: blk=1024 kfbh.block.obj: 2147483648 ; 0x008: disk=0 kfbh.check: 3813974007 ; 0x00c: 0xe3549ff7 kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfdpHdrPairBv1.first.super.time.hi:32999670 ; 0x000: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7de kfdpHdrPairBv1.first.super.time.lo:1788841984 ; 0x004: USEC=0x0 MSEC=0x3e4 SECS=0x29 MINS=0x1a kfdpHdrPairBv1.first.super.last: 2 ; 0x008: 0x00000002 kfdpHdrPairBv1.first.super.next: 2 ; 0x00c: 0x00000002 kfdpHdrPairBv1.first.super.copyCnt: 5 ; 0x010: 0x05 kfdpHdrPairBv1.first.super.version: 1 ; 0x011: 0x01 kfdpHdrPairBv1.first.super.ub2spare: 0 ; 0x012: 0x0000 kfdpHdrPairBv1.first.super.incarn: 1 ; 0x014: 0x00000001 kfdpHdrPairBv1.first.super.copy[0]: 0 ; 0x018: 0x0000 kfdpHdrPairBv1.first.super.copy[1]: 1 ; 0x01a: 0x0001 kfdpHdrPairBv1.first.super.copy[2]: 2 ; 0x01c: 0x0002 kfdpHdrPairBv1.first.super.copy[3]: 3 ; 0x01e: 0x0003 kfdpHdrPairBv1.first.super.copy[4]: 4 ; 0x020: 0x0004 kfdpHdrPairBv1.first.super.dtaSz: 15 ; 0x022: 0x000f kfdpHdrPairBv1.first.asmCompat:186646528 ; 0x024: 0x0b200000 kfdpHdrPairBv1.first.newCopy[0]: 0 ; 0x028: 0x0000 kfdpHdrPairBv1.first.newCopy[1]: 0 ; 0x02a: 0x0000 kfdpHdrPairBv1.first.newCopy[2]: 0 ; 0x02c: 0x0000 kfdpHdrPairBv1.first.newCopy[3]: 0 ; 0x02e: 0x0000 kfdpHdrPairBv1.first.newCopy[4]: 0 ; 0x030: 0x0000 kfdpHdrPairBv1.first.newCopyCnt: 0 ; 0x032: 0x00 kfdpHdrPairBv1.first.contType: 1 ; 0x033: 0x01 kfdpHdrPairBv1.first.spares[0]: 0 ; 0x034: 0x00000000 kfdpHdrPairBv1.first.spares[1]: 0 ; 0x038: 0x00000000 kfdpHdrPairBv1.first.spares[2]: 0 ; 0x03c: 0x00000000 kfdpHdrPairBv1.first.spares[3]: 0 ; 0x040: 0x00000000 kfdpHdrPairBv1.first.spares[4]: 0 ; 0x044: 0x00000000 kfdpHdrPairBv1.first.spares[5]: 0 ; 0x048: 0x00000000 kfdpHdrPairBv1.first.spares[6]: 0 ; 0x04c: 0x00000000 kfdpHdrPairBv1.first.spares[7]: 0 ; 0x050: 0x00000000 kfdpHdrPairBv1.first.spares[8]: 0 ; 0x054: 0x00000000 kfdpHdrPairBv1.first.spares[9]: 0 ; 0x058: 0x00000000 kfdpHdrPairBv1.first.spares[10]: 0 ; 0x05c: 0x00000000 kfdpHdrPairBv1.first.spares[11]: 0 ; 0x060: 0x00000000 kfdpHdrPairBv1.first.spares[12]: 0 ; 0x064: 0x00000000 kfdpHdrPairBv1.first.spares[13]: 0 ; 0x068: 0x00000000 kfdpHdrPairBv1.first.spares[14]: 0 ; 0x06c: 0x00000000 kfdpHdrPairBv1.first.spares[15]: 0 ; 0x070: 0x00000000 kfdpHdrPairBv1.first.spares[16]: 0 ; 0x074: 0x00000000 kfdpHdrPairBv1.first.spares[17]: 0 ; 0x078: 0x00000000 kfdpHdrPairBv1.first.spares[18]: 0 ; 0x07c: 0x00000000 kfdpHdrPairBv1.first.spares[19]: 0 ; 0x080: 0x00000000
以下為PST table block:
kfed read /oracleasm/asm-disk02 aun=1 blkn=3 aus=4194304 |less kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 18 ; 0x002: KFBTYP_PST_DTA kfbh.datfmt: 2 ; 0x003: 0x02 kfbh.block.blk: 1027 ; 0x004: blk=1027 kfbh.block.obj: 2147483649 ; 0x008: disk=1 kfbh.check: 4204644293 ; 0x00c: 0xfa9dc7c5 kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfdpDtaEv1[0].status: 127 ; 0x000: I=1 V=1 V=1 P=1 P=1 A=1 D=1 kfdpDtaEv1[0].fgNum: 1 ; 0x002: 0x0001 kfdpDtaEv1[0].addTs: 2022663849 ; 0x004: 0x788f66a9 kfdpDtaEv1[0].partner[0]: 49154 ; 0x008: P=1 P=1 PART=0x2 kfdpDtaEv1[0].partner[1]: 49153 ; 0x00a: P=1 P=1 PART=0x1 kfdpDtaEv1[0].partner[2]: 49155 ; 0x00c: P=1 P=1 PART=0x3 kfdpDtaEv1[0].partner[3]: 49166 ; 0x00e: P=1 P=1 PART=0xe kfdpDtaEv1[0].partner[4]: 49165 ; 0x010: P=1 P=1 PART=0xd kfdpDtaEv1[0].partner[5]: 49164 ; 0x012: P=1 P=1 PART=0xc kfdpDtaEv1[0].partner[6]: 49156 ; 0x014: P=1 P=1 PART=0x4 kfdpDtaEv1[0].partner[7]: 49163 ; 0x016: P=1 P=1 PART=0xb kfdpDtaEv1[0].partner[8]: 10000 ; 0x018: P=0 P=0 PART=0x2710 kfdpDtaEv1[0].partner[9]: 0 ; 0x01a: P=0 P=0 PART=0x0 kfdpDtaEv1[0].partner[10]: 0 ; 0x01c: P=0 P=0 PART=0x0 kfdpDtaEv1[0].partner[11]: 0 ; 0x01e: P=0 P=0 PART=0x0 kfdpDtaEv1[0].partner[12]: 0 ; 0x020: P=0 P=0 PART=0x0 kfdpDtaEv1[0].partner[13]: 0 ; 0x022: P=0 P=0 PART=0x0 kfdpDtaEv1[0].partner[14]: 0 ; 0x024: P=0 P=0 PART=0x0 kfdpDtaEv1[0].partner[15]: 0 ; 0x026: P=0 P=0 PART=0x0 kfdpDtaEv1[0].partner[16]: 0 ; 0x028: P=0 P=0 PART=0x0 kfdpDtaEv1[0].partner[17]: 0 ; 0x02a: P=0 P=0 PART=0x0 kfdpDtaEv1[0].partner[18]: 0 ; 0x02c: P=0 P=0 PART=0x0 kfdpDtaEv1[0].partner[19]: 0 ; 0x02e: P=0 P=0 PART=0x0 kfdpDtaEv1[1].status: 127 ; 0x030: I=1 V=1 V=1 P=1 P=1 A=1 D=1 kfdpDtaEv1[1].fgNum: 2 ; 0x032: 0x0002 kfdpDtaEv1[1].addTs: 2022663849 ; 0x034: 0x788f66a9 kfdpDtaEv1[1].partner[0]: 49155 ; 0x038: P=1 P=1 PART=0x3 kfdpDtaEv1[1].partner[1]: 49152 ; 0x03a: P=1 P=1 PART=0x0 kfdpDtaEv1[1].partner[2]: 49154 ; 0x03c: P=1 P=1 PART=0x2 kfdpDtaEv1[1].partner[3]: 49166 ; 0x03e: P=1 P=1 PART=0xe kfdpDtaEv1[1].partner[4]: 49157 ; 0x040: P=1 P=1 PART=0x5 kfdpDtaEv1[1].partner[5]: 49156 ; 0x042: P=1 P=1 PART=0x4 kfdpDtaEv1[1].partner[6]: 49165 ; 0x044: P=1 P=1 PART=0xd kfdpDtaEv1[1].partner[7]: 49164 ; 0x046: P=1 P=1 PART=0xc kfdpDtaEv1[1].partner[8]: 10000 ; 0x048: P=0 P=0 PART=0x2710 kfdpDtaEv1[1].partner[9]: 0 ; 0x04a: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[10]: 0 ; 0x04c: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[11]: 0 ; 0x04e: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[12]: 0 ; 0x050: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[13]: 0 ; 0x052: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[14]: 0 ; 0x054: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[15]: 0 ; 0x056: P=0 P=0 PART=0x0 kfdpDtaEv1[1].partner[16]: 0 ; 0x058: P=0 P=0 PART=0x0
aun=1 的最后第二個(gè)block中備份了一份KFBTYP_DISKHEAD
[oracle@mlab2 hzy]$ kfed read /oracleasm/asm-disk02 aun=1 blkn=1022 aus=4194304 |less kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 1022 ; 0x004: blk=1022 kfbh.block.obj: 2147483649 ; 0x008: disk=1 kfbh.check: 3107059260 ; 0x00c: 0xb931f63c kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfdhdb.driver.provstr: ORCLDISK ; 0x000: length=8 kfdhdb.driver.reserved[0]: 0 ; 0x008: 0x00000000 kfdhdb.driver.reserved[1]: 0 ; 0x00c: 0x00000000 kfdhdb.driver.reserved[2]: 0 ; 0x010: 0x00000000 kfdhdb.driver.reserved[3]: 0 ; 0x014: 0x00000000 kfdhdb.driver.reserved[4]: 0 ; 0x018: 0x00000000 kfdhdb.driver.reserved[5]: 0 ; 0x01c: 0x00000000 kfdhdb.compat: 186646528 ; 0x020: 0x0b200000 kfdhdb.dsknum: 1 ; 0x024: 0x0001 kfdhdb.grptyp: 3 ; 0x026: KFDGTP_HIGH kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER kfdhdb.dskname: DATA1_0001 ; 0x028: length=10 kfdhdb.grpname: DATA1 ; 0x048: length=5 kfdhdb.fgname: DATA1_0001 ; 0x068: length=10 kfdhdb.capname: ; 0x088: length=0 kfdhdb.crestmp.hi: 32999670 ; 0x0a8: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7de kfdhdb.crestmp.lo: 1788720128 ; 0x0ac: USEC=0x0 MSEC=0x36d SECS=0x29 MINS=0x1a kfdhdb.mntstmp.hi: 32999670 ; 0x0b0: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7de kfdhdb.mntstmp.lo: 1812990976 ; 0x0b4: USEC=0x0 MSEC=0x3 SECS=0x1 MINS=0x1b kfdhdb.secsize: 512 ; 0x0b8: 0x0200 kfdhdb.blksize: 4096 ; 0x0ba: 0x1000 kfdhdb.ausize: 4194304 ; 0x0bc: 0x00400000
AUN=1 的最后一個(gè)block為KFBTYP_HBEAT 心跳表：
[oracle@mlab2 hzy]$ kfed read /oracleasm/asm-disk02 aun=1 blkn=1023 aus=4194304 |less kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 19 ; 0x002: KFBTYP_HBEAT kfbh.datfmt: 2 ; 0x003: 0x02 kfbh.block.blk: 2047 ; 0x004: blk=2047 kfbh.block.obj: 2147483649 ; 0x008: disk=1 kfbh.check: 1479766671 ; 0x00c: 0x5833728f kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfdpHbeatB.instance: 1 ; 0x000: 0x00000001 kfdpHbeatB.ts.hi: 32999734 ; 0x004: HOUR=0x16 DAYS=0x9 MNTH=0x2 YEAR=0x7de kfdpHbeatB.ts.lo: 3968041984 ; 0x008: USEC=0x0 MSEC=0xe1 SECS=0x8 MINS=0x3b kfdpHbeatB.rnd[0]: 1065296177 ; 0x00c: 0x3f7f2131 kfdpHbeatB.rnd[1]: 857037208 ; 0x010: 0x33155998 kfdpHbeatB.rnd[2]: 2779184235 ; 0x014: 0xa5a6fc6b kfdpHbeatB.rnd[3]: 2660793989 ; 0x018: 0x9e987e85
如下場景中PST 可能被重定位：
Extents Set
extents set 是data extent的集合，以此來維護(hù)virtual extent的冗余拷貝。ASM FILE1 中的extent 指針在extent map中是連續(xù)的，如下面的數(shù)據(jù)：
SQL> select pxn_kffxp,xnum_kffxp from x$kffxp where number_kffxp=257;
PXN_KFFXP XNUM_KFFXP
---------- ----------
0 0
1 0
2 0
3 1
4 1
5 1
6 2
7 2
8 2
9 3
10 3
以上查詢中PXN_KFFXP為文件號257文件的物理extent號，而XNUM_KFFXP為邏輯extent號。 此文件位于一個(gè)High redundancy diskgroup上，所以一個(gè)extent set 包含3份相同的virtual extent數(shù)據(jù)。
可以把上述查詢就看做文件號257文件的extent map，其邏輯extent號是連續(xù)遞增的。
在一個(gè)extent sets中第一個(gè)extent就是primary extent。 在external redundancy模式下僅有一個(gè)primary extent。Normal redundancy下有一個(gè)二級extent在primary之后，high的情況下有2個(gè)二級extent。
對于normal redundancy下的文件，每一個(gè)extent set 都由2個(gè)分布在不同磁盤同時(shí)也是2個(gè)不同failure group的data extent組成。這2個(gè)data extent在extent map上是緊挨著的。primary extent的extent number總是偶數(shù)，其唯一的一個(gè)二級extent總是奇數(shù)。當(dāng)一個(gè)extent被移動時(shí)一般會引發(fā)extent set中所有extent對應(yīng)的移動，以滿足冗余要求。
High Redundancy diskgroup默認(rèn)使用三路鏡像。三路鏡像下的Vritual Extent有一個(gè)primary和2個(gè)二級secondary data extents。secondary data extents需要存放在不同的failure group，所以其要求至少三個(gè)failure group來實(shí)現(xiàn)high redundancy。
在特殊情況下可能存在data extent的丟失，例如當(dāng)failure group不可用導(dǎo)致無處可放時(shí)。
secondary extent將被均勻分配在primary extent對應(yīng)的disk partners上；即便有磁盤失敗仍能保持對extent set的寫出是負(fù)載均衡的。
File Directory (file #1)
具體請參考 深入了解Oracle ASM(二):ASM File number 1 文件目錄 http://www.askmaclean.com/archives/asm-file-number-1-the-file-directory.html
ASM實(shí)例啟動
在ASM文件可以通過ASM實(shí)例來訪問之前，ASM實(shí)例必須先啟動。 在11.2下 不管是RAC還是StandAlone環(huán)境下ASM實(shí)例都會隨系統(tǒng)BOOT自動啟動。 啟動一個(gè)ASM實(shí)例和啟動一個(gè)數(shù)據(jù)庫實(shí)例類似。 SGA和一組后臺進(jìn)程在啟動過程中被創(chuàng)建出來。初始化參數(shù)instance_type決定了是ASM 實(shí)例還是數(shù)據(jù)庫實(shí)例。除非STARTUP時(shí)使用了 NOMOUNT選項(xiàng)，否則默認(rèn)STARTUP會執(zhí)行ALTER DISKGROUP ALL MOUNT。
ASM實(shí)例啟動過程中將加入到CSS中的+ASM成員組中。這將允許本實(shí)例與其他+ASM實(shí)例共享鎖。數(shù)據(jù)庫實(shí)例不會加入到這個(gè)成員組中，因?yàn)閿?shù)據(jù)庫實(shí)例的實(shí)例名不能以”+”開頭。
Discovery 發(fā)現(xiàn)磁盤
Discovery 過程是在找到磁盤以便后續(xù)的操作。Discovery 到DISK STRING匹配的位置去找尋磁盤，并返回那些其認(rèn)為合適的磁盤。對discovery一般存在于2種場景下； 第一種是使用asm_diskstring中指定的所有字符串來找出所有ASM實(shí)例必要訪問的磁盤。 第二種是指定磁盤路徑用以create diskgroup或者add disk to diskgroup。
第一種discovery也叫做shallow discovery， 只會返回asm_diskstring指定下的磁盤。第二種也叫做deep discovery，是讀取每一個(gè)磁盤的第一個(gè)塊。 disk header在這里用以分類磁盤是否可用，是被ASM外的其他東西實(shí)用(例如LVM)，還是已經(jīng)被其他diskgroup實(shí)用。discovery操作并不會 mount diskgroup或者寫任何磁盤頭。
Create Disk Group 創(chuàng)建磁盤組
創(chuàng)建diskgroup 需要指定多個(gè)磁盤路徑，且這些磁盤需要通過如下的檢測：
所有的磁盤均會以寫入一個(gè)disk header的形式來驗(yàn)證。該 disk header中mount timestamp為0 ，由此可知diskgroup還沒有被mount 過。之后free space block和allocation table blocks 元數(shù)據(jù)塊將被寫入。
其中部分磁盤被選出來 存放Partnership and Status Table ，PST 表。 PST被初始化記錄所有的磁盤為在線狀態(tài)。High redundancy disk group 每一個(gè)failure group對應(yīng)一個(gè) PST，最多5個(gè)拷貝。 normal redundancy group至多3個(gè)PST拷貝。external redundancy disk group有一個(gè)PST。
接著后續(xù)的metadata block將被初始化，并均勻分布在新創(chuàng)建的diskgroup的所有磁盤上。
【Oracle ASM Metadata】Alias Directory (file #6)
【Oracle ASM】Continuing Operations Directory (file #4)
【Oracle ASM Metadata】Template Directory (file #5)
【Oracle ASM】ASM FILE NUMBER 3 Active Change Directory
深入了解Oracle ASM(二):ASM File number 1 文件目錄
【Oracle ASM】ASM FILE NUMBER #2 DISK Directory
當(dāng)diskgroup完全初始化完成后mount timestamp將寫入到disk header。 這將標(biāo)記diskgroup已經(jīng)格式好并可以被mount。其他實(shí)例也可以mount該disk group。
Drop Disk Group
diskgroup 可以被drop掉的前提是其上所有的文件都處于關(guān)閉狀態(tài)且僅有本地實(shí)例在mount它。 可以通過在集群件的所有ASM上通信來確認(rèn)這2點(diǎn)。drop diskgroup會在該DG下所有的磁盤頭寫入header_status為FORMER狀態(tài)。
Mount Disk Group
Mount Disk Group使Disk Group其對本地ASM 實(shí)例和連接到該實(shí)例的數(shù)據(jù)庫實(shí)例可用。 在該diskgroup中的文件在 OPEN/create/delete之前必須先被本地ASM實(shí)例mount； 一般啟動ASM時(shí)同時(shí)mount 多個(gè)diskgroup較高效。 典型情況下是ASM_DISKGROUPS匹配到的所有的diskgroup均通過ALTER DISKGROUP ALL MOUNT 在ASM實(shí)例啟動時(shí)被mount 。
下面是mount 一個(gè)diskgroup的步驟：
Discovery
會通過ASM_DISKSTRING.做一個(gè)deep discovery； 每一個(gè)disk header均包含了其所屬于的diskgroup；該步驟應(yīng)當(dāng)要找到所有要被mount 的diskgroup下屬的所有磁盤。 在disk header上獲得如下信息：
當(dāng)discovery時(shí)若發(fā)現(xiàn)2個(gè)磁盤的disk header一樣則可能報(bào)錯(cuò)，這樣做的目的是為了避免損壞disk group。
注意從diskgroup創(chuàng)建之后每一個(gè)ASM DISK的OS設(shè)備名可能發(fā)生變化，或者在集群中的每個(gè)節(jié)點(diǎn)上都不一樣，這不要緊只需要discovery能找到它們并通過驗(yàn)證即可。
第一次mount的實(shí)例
會通過Instance Lock實(shí)例鎖來判斷ASM實(shí)例是否是第一個(gè)mount 該diskgroup的，還是已經(jīng)被其他ASM實(shí)例 mount 了。如果是第一個(gè)做mount的，那么鎖會被以排他持有直到mount disk group初始化完成，以防止其他實(shí)例也在該過程中做mount。 如果不是第一個(gè)mount的，那么要等第一個(gè)mount的ASM完成其mount操作。
PST discovery
當(dāng)diskgroup的一組磁盤被找到，必須要找到包含PST的那些磁盤。 每一個(gè)磁盤上的AUN=1的第一個(gè)塊將被讀取。這樣來識別那些盤在AUN=1中存有PST拷貝。必須找到多數(shù)相同的PST拷貝來保證讀出一個(gè)有效的PST。
例如如果有5個(gè)PST， 則需要找到3份內(nèi)容一樣的 PST并讀出。
一旦PST被讀取后，ASM實(shí)例將知道m(xù)ount disk group必須要哪些個(gè)些disk number。
Heartbeat
如果是第一個(gè)mount的實(shí)例，那么會做一個(gè)heartbeat check心跳檢查。這是為了防止2個(gè)不同主機(jī)上的實(shí)例都認(rèn)為其實(shí)第一個(gè)mount該diskgroup的，這種現(xiàn)象可能發(fā)生在lock manager配置不當(dāng)?shù)膱鼍爸小．?dāng)disk group被實(shí)例mount時(shí)，PST 表上的最后一個(gè)塊即心跳塊每3秒被寫入新的值，這種寫入是由已經(jīng)mount該DG的實(shí)例中的一個(gè)執(zhí)行 。 若一個(gè)實(shí)例自認(rèn)為第一個(gè)mount，但是缺發(fā)現(xiàn)了heartbeat則其mount 失敗。若其發(fā)現(xiàn)沒有heartbeat，則其將開始heartbeat。
Header validation
若是第一個(gè)mount dg的實(shí)例則一個(gè)新的mount 時(shí)間戳timestamp被寫入到各個(gè)磁盤。 若不是第一個(gè)mount的實(shí)例，則會驗(yàn)證該mount timestamp。這保證2個(gè)實(shí)例可能找到對一個(gè)磁盤的多份完全相同的拷貝時(shí)，仍能分辨出其實(shí)是不同的磁盤。
若是第一個(gè)mount的實(shí)例，則可能存在這種情況：上一次mount以來的部分磁盤變得不可用了； 但這些磁盤在PST中仍標(biāo)記為在線的，但卻找不到它們了。這個(gè)差異將被ASM發(fā)現(xiàn)并將丟失的磁盤OFFLINE掉，前提是其redundancy允許這些磁盤OFFLINE。
若不是第一個(gè)mount的實(shí)例則在PST中所有標(biāo)記為ONLINE 的磁盤均需要被其所發(fā)現(xiàn)。若其他實(shí)例能發(fā)現(xiàn)DG下的所有磁盤，那么本實(shí)例必須也能看到。
Redo recovery
若本實(shí)例時(shí)第一個(gè)mount DG的， 則其有義務(wù)做crash recovery。若ACD 中的任意redo thread 在他們的檢查點(diǎn)記錄中標(biāo)記為打開狀態(tài)，則它們需要被recover。 這個(gè)工序和數(shù)據(jù)庫的crash recovery很像。在檢查點(diǎn)和最后寫入記錄之間的redo將被掃描，來找出那些塊需要恢復(fù)。這些塊將被讀取并應(yīng)用 redo。
Redo thread selection
ACD中需要找出一塊未使用的區(qū)域來存放本實(shí)例生成的redo。 若是第一個(gè)mount DG的實(shí)例則需要保證所有thread 都處于關(guān)閉狀態(tài)，由此最小的thread將必然可用。 若不是第一個(gè)MOUNT DG的實(shí)例則可能整個(gè)ACD均已被使用。 若遇到此場景，則mount 中的實(shí)例將要求已mount 實(shí)例去擴(kuò)展ACD。一旦ACD擴(kuò)容了新區(qū)域以便存放生成的redo，則另一個(gè)redo thread將以寫出到checkpoint block的形式來標(biāo)記為OPEN。
First done
若是第一個(gè)mount DG的實(shí)例，將開始允許其他實(shí)例也能mount該DG。 若第一個(gè)實(shí)例到這一步之前就crash了，則其他實(shí)例將認(rèn)為自己是第一個(gè)mount DG的實(shí)例。則若在多于2個(gè)實(shí)例的集群中后續(xù)的mount可以并行運(yùn)行了。
Registration
實(shí)例將自己已mount的DG信息注冊到CSS中。嘗試訪問這些DG的數(shù)據(jù)庫實(shí)例將發(fā)現(xiàn)這些CSS注冊信息并連接到ASM實(shí)例以便訪問DG。
COD recovery
若是第一個(gè)mount DG的實(shí)例，其會檢查COD中的記錄，若發(fā)現(xiàn)任何操作需要回滾，則將其回滾。若有一個(gè) rebalance作業(yè)仍在過程中，則該實(shí)例的 RBAL將重新啟動rebalance。
Dismount Disk Group
如同mount是ASM實(shí)例本地操作，dismount也是這樣。正常情況下當(dāng)本地?cái)?shù)據(jù)庫實(shí)例還有訪問diskgroup中文件時(shí)是不允許常規(guī)的dismount的。 若如果沒有文件被打開訪問，則ASM buffer cache中的臟塊將被寫出到磁盤，且在ACD中的checkpoint記錄將被標(biāo)記為線程已關(guān)閉。且SGA中描述diskgroup的部分將被釋放。
強(qiáng)制FORCE Dismount Disk Group也是常有的事情，當(dāng)某個(gè)磁盤失敗導(dǎo)致冗余算法無法容忍時(shí)就會自動觸發(fā)強(qiáng)制dismount。 舉個(gè)例子來說，當(dāng)external redundancy下數(shù)據(jù)未做任何鏡像，則當(dāng)ASM中cache無法寫出時(shí)除了強(qiáng)制dismount外沒有其他選擇。
Add Disk
增加磁盤add disk的命令將針對 指定的discovery strings去識別磁盤，若此時(shí)發(fā)現(xiàn)的磁盤已經(jīng)是disk group的一部分，則將被默許為忽略掉。 磁盤將允許被加入到diskgroup，前提是：
當(dāng)所有的磁盤均被以上驗(yàn)證過后，下面的步驟將被執(zhí)行：
當(dāng)rebalance開始時(shí)這個(gè)add disk操作就被返回。 磁盤并不完全參與到disk group 中，直到rebalance結(jié)束。
ASM Drop Disk
磁盤可以從diskgroup中drop出來的前提是 有足夠的未用空間在剩余的磁盤上。 即便其仍在被活躍使用也還是可以被 drop的。 當(dāng)磁盤仍在工作，但是對于diskgroup不是必須的時(shí)可以做常規(guī)的drop。若磁盤失敗時(shí)則可以用FORCE選項(xiàng)。 Drop磁盤將影響所有mount diskgroup 的實(shí)例。其不是一個(gè)實(shí)例本地操作。
ASM DROP Normal 常規(guī)drop
常規(guī)drop disk下磁盤將被標(biāo)記為不可再分配，且開始一個(gè)rebalance。 drop命令當(dāng)rebalance開始時(shí)即返回。在 rebalance過程中該drop中的磁盤將不斷被移動其上的內(nèi)容到其他磁盤上。 當(dāng)rebalance 完成時(shí)該磁盤將被從disk group中移除并可以復(fù)用。 可以通過查詢V$ASM_DISK來確認(rèn)磁盤是否還是disk group的一部分。
當(dāng)rebalance還在進(jìn)行中時(shí)，disk將處于正被drop的狀態(tài)，即dropping。 還可以通過命令 alter diskgroup undrop來反轉(zhuǎn)這個(gè)還未完成的drop命令的效果。 如此則磁盤上不可再分配的標(biāo)記將被移除，并會重啟一個(gè)rebalance。 這個(gè)重啟的rebalance將重新評估我們正在drop的磁盤的partnerships,并可能將數(shù)據(jù)data extent移回到正被dropping的磁盤上。 這個(gè)重啟的rebalance 僅僅需要撤銷之前rebalance所做的工作即可， 因此其所耗時(shí)間取決于之前的drop工作的rebalance的工作量。 最后的分配情況可能與開始有著些許區(qū)別，但其仍將是平衡的。
ASM DROP Force 強(qiáng)制drop
對于Normal 或者 High Redundancy disk group而言一個(gè)磁盤可以使用FORCE選項(xiàng)被DROP。FORCE 選項(xiàng)對于external redundancy 的disk group而言是不可用的， 原因是無法正常從被drop掉的disk上將數(shù)據(jù)重構(gòu)出來。 對于normal或者h(yuǎn)igh redundancy的disk group而言如果有一個(gè)或者多個(gè)磁盤partners已經(jīng)OFFLINE了，則可能也不允許FORCE DROP。 總是當(dāng)FORCE DROP可能造成丟失文件上數(shù)據(jù)的時(shí)候都不允許使用。
FORCE DROP會立即將磁盤狀態(tài)置為OFFLINE。該磁盤上的所有extent都將脫離其對應(yīng)的extent set集合，這意味著冗余度的降低。 該磁盤將從disk directory中被移除，PST中也是這樣。
該磁盤的disk header將被寫入信息來表明其不再是disk group的一部分。 rebalance也會被啟動。 當(dāng)drop force命令返回時(shí)，意味著磁盤已經(jīng)完全從disk group中移除了，可以被重用，也可以從操作系統(tǒng)上斷開了。
發(fā)生操作的disk group上所有文件的冗余度要直到rebalance才能重新完善。 與常規(guī)的drop不同，顯然force drop是無法被undrop的。磁盤將完全被從disk group移除，所以undrop也無法撤銷此操作； 所能做的是將該磁盤重新加入到diskgroup， add disk。
數(shù)據(jù)庫實(shí)例如何連接到ASM
當(dāng)數(shù)據(jù)庫實(shí)例嘗試打開或者創(chuàng)建名字以“+”開頭的文件時(shí)， 它會通過CSS來查看disk group和mount該DG的ASM實(shí)例的信息。 如果數(shù)據(jù)庫實(shí)例之前訪問過其他Disk Group里的文件，則將使用同一個(gè)ASM實(shí)例。 如果這是第一次訪問ASM上的文件，數(shù)據(jù)庫實(shí)例就需要連接到ASM實(shí)例了。 下面為數(shù)據(jù)庫實(shí)例準(zhǔn)備訪問ASM上文件的步驟：
后臺進(jìn)程ASMB啟動并connect連接到ASM實(shí)例。 數(shù)據(jù)庫實(shí)例所打開的任意文件的extent map盤區(qū)圖被發(fā)送給ASMB后臺進(jìn)程。 其有義務(wù)去維護(hù)extent map。若發(fā)生任何extent移位，則ASM實(shí)例將更新發(fā)送給數(shù)據(jù)庫實(shí)例的ASMB進(jìn)程。I/O統(tǒng)計(jì)信息定期由ASMB進(jìn)程反饋給ASM實(shí)例。
RBAL后臺進(jìn)程啟動，其對disk group下的所有磁盤做全局打開操作，其類似于DBWR進(jìn)程全局打開數(shù)據(jù)文件。此全局打開允許數(shù)據(jù)庫實(shí)例訪問diskgroup中的任意文件。 若還有其他disk group需要被訪問，則 RBAL也將打開對應(yīng)diskgroup下的所有磁盤。 對add加入或者drop的磁盤，RBAL也會打開和關(guān)閉它們。 關(guān)于磁盤的訊息先是發(fā)送給ASMB，之后ASMB轉(zhuǎn)發(fā)給RBAL。
會創(chuàng)建一個(gè)連接池，一組slave進(jìn)程將建立到ASM實(shí)例的連接。數(shù)據(jù)庫進(jìn)程若需要發(fā)送信息給ASM實(shí)例，則需要使用這些slave進(jìn)程。 舉個(gè)例子來說，打開一個(gè)文件，將通過slave給ASM發(fā)送一個(gè)OPEN的請求。 但對于長時(shí)間運(yùn)行的操作例如創(chuàng)建文件，則不使用slave。
ASM file Create文件創(chuàng)建
文件創(chuàng)建這個(gè)過程，是數(shù)據(jù)庫發(fā)送請求給ASM實(shí)例，ASM創(chuàng)建文件并響應(yīng)該請求。
創(chuàng)建文件時(shí)會為其分配空間并打開文件以便讀寫。一旦文件完成初始化，則創(chuàng)建被提交。 如果創(chuàng)建文件未被提交則文件會被自動刪除。 其步驟如下：
數(shù)據(jù)庫進(jìn)程調(diào)用服務(wù)層代碼來創(chuàng)建一個(gè)文件名以”+”開頭的文件， 系統(tǒng)將自動返回一個(gè)生成的名字。 如果文件名里給出了完全路徑則一個(gè)用戶別名將被創(chuàng)建并返回。該調(diào)用同樣包括 文件類型、塊大小、初始文件大小和構(gòu)建系統(tǒng)聲稱文件名的其他信息。
數(shù)據(jù)庫進(jìn)程連接到ASM實(shí)例，此處不用connection pool連接池，原因是文件創(chuàng)建要求保持在同一連接內(nèi)。 這避免了使用過多連接池連接而可能造成的死鎖。
數(shù)據(jù)庫進(jìn)程發(fā)送創(chuàng)建請求給ASM實(shí)例，需要等待新文件的extent map被加載到數(shù)據(jù)庫實(shí)例中
ASM前臺進(jìn)程為新文件分配一個(gè)文件目錄下的記錄，并在COD continuing operations directory中創(chuàng)建一個(gè)回滾記錄，以便刪除該文件。 如果連接被打斷，ASM前臺進(jìn)程崩潰，或者數(shù)據(jù)庫中止該創(chuàng)建，則回滾該操作時(shí)將自動刪除該文件。
ASM進(jìn)程為該文件分配extent，以便其均勻分布在disk group中的所有磁盤上。
ASM實(shí)例發(fā)送extent map 給數(shù)據(jù)庫實(shí)例的ASMB進(jìn)程
ASM前臺進(jìn)程將文件名返回給數(shù)據(jù)庫進(jìn)程，數(shù)據(jù)庫進(jìn)程會保持與ASM進(jìn)程之間的連接為打開
數(shù)據(jù)庫進(jìn)程為新的文件初始化內(nèi)容，可給出resize請求以便擴(kuò)大或收縮該文件
當(dāng)文件的內(nèi)容和大小都初始化后，一個(gè)提交該創(chuàng)建的請求將發(fā)送給ASM前臺進(jìn)程
ASM前臺進(jìn)程在 alias目錄下創(chuàng)建系統(tǒng)生成文件名的記錄。 如果還有用戶指定的 alias，則該alias文件名也將加入到alias directory
ASM將該文件標(biāo)記為創(chuàng)建成功的，并刪除回滾記錄
由于提交創(chuàng)建也將關(guān)閉文件，故 ASM實(shí)例告訴數(shù)據(jù)庫ASMB進(jìn)程要釋放其extent map
ASM前臺進(jìn)程返回一個(gè)成功創(chuàng)建文件的信息給數(shù)據(jù)庫進(jìn)程。 數(shù)據(jù)庫進(jìn)程關(guān)閉到ASM實(shí)例的連接，其將終止對應(yīng)的ASM前臺進(jìn)程
以上文件被成功創(chuàng)建并可以被任何進(jìn)程打開了
Extent Allocation 盤區(qū)分配
分配盤區(qū)Allocating extents，將文件均勻地發(fā)布在disk Group中的所有磁盤上。 每一個(gè)磁盤有一個(gè)權(quán)重，這個(gè)權(quán)重是基于其大小的。extent set下屬的data extents必須分配在disk partnerships之間。 每一個(gè)extent set的primary extent分配時(shí)會按照磁盤的權(quán)重來分布文件。則文件的下一個(gè)primary extent將盡可能分配在那些使文件分布更平衡的磁盤上。這樣同一個(gè)文件在同一個(gè)磁盤上的primary extent會盡可能遠(yuǎn)。
對于Normal 或者 high redundancy的 文件的secondary extents必須為primary extent多冗余拷貝而分配。secondary extents理想是均勻分布在primary extent所在盤的partners disk上，同樣也要基于磁盤權(quán)重。對于high redundancy還有一個(gè)要求，就是2個(gè)secondary extents需要分配在不同的failure group上。
FILE Delete ASM文件刪除
ASM上的文件可以通過 數(shù)據(jù)庫實(shí)例 或者在ASM實(shí)例中輸入一條SQL命令來刪除。 數(shù)據(jù)庫實(shí)例可以通過連接池中的slave進(jìn)程來發(fā)送一個(gè)delete 刪除請求。若該文件還處于打開狀態(tài)則文件暫時(shí)不能刪除。 針對一個(gè)打開的文件，每一個(gè)ASM實(shí)例將持有一個(gè)全局鎖來避免其被刪除。 回滾記錄也將介入，以保證如果刪除開始，其必須完成。
FILE OPEN ASM文件打開
當(dāng)一個(gè)數(shù)據(jù)庫實(shí)例下的進(jìn)程打開一個(gè)ASM 文件時(shí)，它會使用連接池slave進(jìn)程來發(fā)送請求給ASM實(shí)例。 ASM前臺進(jìn)程會查看alias directory下的文件，或使用系統(tǒng)生成的文件名中的文件號和incarnation信息。 ASM前臺進(jìn)程獲取文件鎖并發(fā)送extent map給數(shù)據(jù)庫的 ASMB進(jìn)程，并存在SGA中。 一旦extent map加載成功，ASM將返回成功信息給數(shù)據(jù)庫進(jìn)程。 數(shù)據(jù)庫進(jìn)程使用extent map來將文件訪問轉(zhuǎn)換為適合的磁盤IO。每一個(gè)extent指針存有一個(gè)check檢測值，來捕獲是否存在損壞的extent map。
若果數(shù)據(jù)庫實(shí)例的一個(gè)進(jìn)程打開一個(gè)文件，則其他進(jìn)程可以使用同一個(gè)extent map。因此僅僅有第一個(gè)進(jìn)程需要與ASM 實(shí)例聯(lián)系。數(shù)據(jù)庫實(shí)例的其他進(jìn)程是坐享其成的。
FILE Close 關(guān)閉文件
當(dāng)數(shù)據(jù)庫實(shí)例中的所有進(jìn)程均關(guān)閉了一個(gè)文件，則connection pool連接池slave進(jìn)程將發(fā)送一個(gè)close信息給ASM實(shí)例。 ASM實(shí)例會通知數(shù)據(jù)庫的ASMB進(jìn)程要關(guān)閉extent map和釋放extent map所占內(nèi)存。當(dāng)ASMB關(guān)閉進(jìn)程后其將釋放文件鎖。
I/O 錯(cuò)誤
Normal或者 high redundancy的disk group可以容忍多種 IO錯(cuò)誤。 處理這些IO錯(cuò)誤的方式 基于 I/O的類型：是讀還是寫？以及 其I/O 的原因。 最常見的處理方式是當(dāng)發(fā)生I/O錯(cuò)誤則將問題磁盤OFFLINE掉。 如果將磁盤OFFLINE掉將造成部分?jǐn)?shù)據(jù)不可用，則強(qiáng)制性的Disk Group Dismount將被發(fā)動。 這樣做則從其他節(jié)點(diǎn)或者待問題修復(fù)后，嘗試恢復(fù)重新寫入變得可能。 在external redundancy下磁盤不能被offline。 normal redundancy下2個(gè)互為partners的磁盤不能同時(shí)OFFLINE。high redundancy下2個(gè)partners可以O(shè)FFLINE，其他partners不能再OFFLINE。 如果一個(gè)錯(cuò)誤引發(fā)disk group被強(qiáng)制dismount，則沒有磁盤將被OFFLINE。如果normal disk group下2份數(shù)據(jù)寫入都有問題，則也不會吧磁盤OFFLINE。
一個(gè)磁盤要OFFLINE的話，首先要求所有的數(shù)據(jù)庫實(shí)例和ASM實(shí)例均在自己的SGA中將其標(biāo)記為OFFLINE的，避免其仍正在被讀取。 由于 I/O錯(cuò)誤導(dǎo)致磁盤OFFLINE的行為，直到所有進(jìn)程均停止讀取該磁盤才被認(rèn)為是完成的。
ASM FILE read 文件讀取
注意文件數(shù)據(jù)的讀取仍是數(shù)據(jù)庫實(shí)例自己完成的，而不是ASM實(shí)例。 典型情況下總是讀取primary extent除非對應(yīng)的磁盤OFFLINE了。 如果primary extent 所在磁盤OFFLINE了或者讀取失敗了，則會使用secondary extents。 如果primary 和 secondary extents都讀取失敗，則一個(gè)I/O錯(cuò)誤將返回給 client。 文件讀取失敗一般不會造成磁盤OFFLINE或者disk group dismount。
ASM FILE Write 寫文件
文件數(shù)據(jù)寫入同樣仍由數(shù)據(jù)庫實(shí)例自己完成，而非ASM實(shí)例。若任何寫出發(fā)生IO錯(cuò)誤，則該錯(cuò)誤將通過connection pool slave連接池子進(jìn)程發(fā)送給ASM實(shí)例。 ASM實(shí)例要么把磁盤OFFLINE，要么dismount diskgroup，且通過ASMB的連接來更新磁盤狀態(tài)。 數(shù)據(jù)庫進(jìn)程或者重新發(fā)起之前的寫出。由于寫出不會再寫到OFFLINE的磁盤上，所以重試寫出一般會成功，除非diskgroup也給dismount了。
Instance Recovery實(shí)例恢復(fù)
ASM實(shí)例恢復(fù)instance recovery 與數(shù)據(jù)庫實(shí)例恢復(fù)很類似。最大的區(qū)別在于ASM實(shí)例會mount多個(gè)disk group，且不同的disk group又可以為多個(gè)實(shí)例所用。Instance recovery是基于每一個(gè)disk group為基礎(chǔ)的。在RAC中若一個(gè)實(shí)例強(qiáng)制dismount了一個(gè)disk group，則另一個(gè)ASM實(shí)例必須做該disk group的instance recovery，甚至于之前dismount該diskgroup的實(shí)例沒有終止。ASM實(shí)例只為其已經(jīng) mount的disk group做instance recovery。RAC中，如果一個(gè)ASM實(shí)例已經(jīng)mount了2個(gè)disk group且意外崩潰了，則這2個(gè)disk group的恢復(fù)工作可能有集群的其他ASM實(shí)例來完成。
instance recovery實(shí)例恢復(fù)首先掃描ACD中的redo來構(gòu)建需要做恢復(fù)的塊的列表。 redo將被應(yīng)用到塊，塊將被寫回到diskgroup中。 之后新的鎖可以被請求以便訪問diskgroup上的元數(shù)據(jù)metadata。注意ASM實(shí)例的instance recovery僅僅與 ASM metadata有關(guān)。 文件中的數(shù)據(jù)還是由數(shù)據(jù)庫實(shí)例自己恢復(fù)的。
在redo應(yīng)用之后正執(zhí)行該instance recovery的ASM實(shí)例將檢測COD中的數(shù)據(jù)，如果之前有rebalance正在之前崩潰的實(shí)例中運(yùn)行的話， 則考慮如果必要重啟該 rebalance 。 之前崩潰的ASM實(shí)例所留下的任意回滾操作都將被完成。
Rebalance
當(dāng)一個(gè)或者多個(gè)磁盤 被 加入，drop，或者resize時(shí)disk group要做rebalance來保證所有存儲均勻地使用。Rebalance移動數(shù)據(jù)的依據(jù)不是 I/O統(tǒng)計(jì)信息，也不是其他統(tǒng)計(jì)的結(jié)果。 完全基于disk group中各個(gè)磁盤的大小。當(dāng)存儲配置發(fā)生變化時(shí)其自動開始，當(dāng)然也可以手動來發(fā)起。一般不推薦手動介入，需要手動介入的是當(dāng)需要修改 rebalance power，或者將rebalance操作變換到其他節(jié)點(diǎn)上執(zhí)行時(shí)。 手動介入時(shí)命令在哪個(gè)實(shí)例上執(zhí)行，rebalance就發(fā)生在哪個(gè)實(shí)例上。
下面是rebalance 的簡要步驟：
Repartner 重新配對
當(dāng)一個(gè)磁盤加入到diskgroup中時(shí)，其需要配對partners，這樣它本身存放數(shù)據(jù)的primary extent，其配對partners磁盤才能存儲鏡像拷貝。由于理想情況下每一個(gè)磁盤已經(jīng)擁有了最大數(shù)目的配對partners，新增加磁盤配對關(guān)系的話往往意味著要打破一些現(xiàn)有的partners配對。 當(dāng)正在drop磁盤時(shí)，其現(xiàn)有的配對關(guān)系partnerships將不得不被打破。這將造成一些磁盤的配對數(shù)目小于理想數(shù)。 因此rebalance的第一步是重新計(jì)算一個(gè)新的配對組合集合。 這個(gè)新的partnerships基于移動最少量數(shù)據(jù)的依據(jù)被選擇出來。這也是為什么最好增加和drop多個(gè)磁盤最好是同一時(shí)間發(fā)起的原因。
Calculate weights計(jì)算權(quán)重
rebalance的目標(biāo)是讓disk group 中的每一個(gè)磁盤均以同樣的比例分配。因此更大的磁盤就要存放更多的文件數(shù)據(jù)。 這里會為每一個(gè)磁盤計(jì)算一個(gè)權(quán)重，來決定其上存放多少量的數(shù)據(jù)。權(quán)重受到磁盤大小和配對關(guān)系的影響。
Scan files 掃描文件
rebalance是一個(gè)文件、一個(gè)文件做的，文件的extent map將被掃描來判斷其應(yīng)當(dāng)如何平衡。為了實(shí)現(xiàn)平衡，現(xiàn)有的extent set可能被移動到其他磁盤上，以便歸于平衡。 這通常結(jié)果是移動到最新加入的磁盤中。也可能為了新的配對關(guān)系來做必要的移動。
Extent relocation 盤區(qū)移位
移位一個(gè)extent 是需要協(xié)調(diào)發(fā)生到該 extent上的任意I/O的。 集群中的所有ASM實(shí)例均會被通知開始移位的信息。 此信息也將被轉(zhuǎn)發(fā)給所有有打開該文件的數(shù)據(jù)庫實(shí)例的ASMB進(jìn)程，這樣就鎖住了對應(yīng)的extent。任何新的寫入到對應(yīng)extent的操作將被阻塞， 但讀取則不被影響。當(dāng)relocate操作結(jié)束后，已有的寫出操作將被重新觸發(fā)。 extent 盤區(qū)是被從舊的位置讀取并寫出到新的位置 基于1MB的I/O。在 relocation完成后解鎖的信息將傳達(dá)并包含有新的盤區(qū)指針。 extent map將被更新 且其上面lock的標(biāo)記將被清楚。 任何未完成的寫入將被允許繼續(xù)工作。 任何活動的查詢將被重新觸發(fā)，原因是舊有的extent可能已經(jīng)被其他數(shù)據(jù)重用了。
可能有多個(gè)slave進(jìn)程在同一時(shí)間做relocation，power limit參數(shù)控制slave進(jìn)程數(shù)目。
Restart重新開始
同時(shí)時(shí)間只能有一個(gè) rebalance。若進(jìn)行中的rebalance被打斷，那么其一般會自動重啟。若正在做rebalance的一個(gè)節(jié)點(diǎn)發(fā)生失敗，則rebalance將從其殘局重啟。如果管理員手動修改了power limit 也會引起重啟。如果在rebalance過程中發(fā)生了另一個(gè)存儲變更，則整個(gè)rebalance將從開頭重啟
Check Disk Group檢測磁盤組
check disk group 命令比對一個(gè) disk group中的冗余數(shù)據(jù)結(jié)構(gòu)來保證沒有損壞發(fā)生。 在檢測過程中數(shù)據(jù)結(jié)構(gòu)將被鎖住，檢測中將發(fā)生下面的動作：
PST將被驗(yàn)證來確保所有的配對關(guān)系是對稱的且有效的。 如果disk A以Disk B作為partner，則Disk B也是Disk A的partner。 如果Disk B不存在或者 Disk A不在Disk B的partner 列表上，則生成錯(cuò)誤。 A和B當(dāng)然在不同的failure groups上。
Extent Map 將對照allocation tables做檢查。所有在線的磁盤的allocation tables將被掃描，且extent map上每一個(gè)已經(jīng)分配的AU將被確認(rèn)。一個(gè)已經(jīng)分配的 AU的allocation tables記錄指出了使用該AU的文件號和data extent信息。文件的extent map中的磁盤和AU信息將被驗(yàn)證。如果文件不存在，或者extent map指向不同的AU，都將導(dǎo)致報(bào)錯(cuò)。 同時(shí)檢測也會發(fā)現(xiàn)那些看上去已經(jīng)被分配，但是不屬于任何文件的一部分的AU。
Allocation tables將對照Extent Map做檢查。所有文件的extent maps將被掃描，且每一個(gè)data extent的分配記錄將被確認(rèn)指向了文件extent。data extent的extent map記錄給出了分配該extent的磁盤號和AU號。allocation table記錄將被驗(yàn)證。 如果磁盤過小，或者AU實(shí)際上沒被分配，或者AU其實(shí)分配給了其他文件，或者AU其實(shí)是分配給其他extent的，都會導(dǎo)致報(bào)錯(cuò)。 該檢測可以發(fā)現(xiàn)被分配了2次的AU，或者雖然標(biāo)記為空閑但實(shí)際已經(jīng)被使用的AU。
所有的extent set都對照著配對關(guān)系partnerships做一次驗(yàn)證。每一個(gè)extent set中的每一個(gè)secondary extent都被驗(yàn)證是否在含有primary extent的磁盤的partner上。 這將發(fā)現(xiàn)丟失配對關(guān)系的情況。
若以上任何問題發(fā)生，則將報(bào)錯(cuò)，但檢測會持續(xù)下去。修復(fù)不一致往往需要靠手動操作，例如使用KFED。
相關(guān)文章鏈接：
Asm Instance Parameter Best Practice
為什么RHEL 6上沒有ASMLIB?
Unix上如何查看文件名開頭為”+asm”的TRACE文件
asm_power_limit對IO的影響
針對11.2 RAC丟失OCR和Votedisk所在ASM Diskgroup的恢復(fù)手段
10g ASM lost disk log
11gR2 RAC ASM啟動揭秘
在11gR2 RAC中修改ASM DISK Path磁盤路徑
在Linux 6上使用UDEV解決RAC ASM存儲設(shè)備名問題
Script:找出ASM中的Spfile參數(shù)文件
如何診斷ASMLIB故障
Script:收集ASM診斷信息
Comparation between ASM note [ID 373242.1] and note [ID 452924.1]
Why ASMLIB and why not?
ASM file metadata operation等待事件
幾個(gè)關(guān)于oracle 11g ASM的問題
利用UDEV服務(wù)解決RAC ASM存儲設(shè)備名
Discover Your Missed ASM Disks
Oracle內(nèi)部視圖X$KFFXP
Fixed X$ Tables in ASM
了解AMDU工具生成的MAP文件
使用AMDU工具從無法MOUNT的DISKGROUP中抽取數(shù)據(jù)文件
深入了解Oracle ASM(一):基礎(chǔ)概念
About Me
...............................................................................................................................
● 本文整理自網(wǎng)絡(luò) http://www.askmaclean.com/archives/know-oracle-asm-basic-html.html
● 本文在itpub（http://blog.itpub.net/26736162）、博客園（http://www.cnblogs.com/lhrbest）和個(gè)人微信公眾號（xiaomaimiaolhr）上有同步更新
● 本文itpub地址：http://blog.itpub.net/26736162/abstract/1/
● 本文博客園地址：http://www.cnblogs.com/lhrbest
● 本文pdf版及小麥苗云盤地址：http://blog.itpub.net/26736162/viewspace-1624453/
● 數(shù)據(jù)庫筆試面試題庫及解答：http://blog.itpub.net/26736162/viewspace-2134706/
● QQ群：230161599 微信群：私聊
● 聯(lián)系我請加QQ好友(646634621)，注明添加緣由
● 于 2017-06-02 09:00 ~ 2017-06-30 22:00 在魔都完成
● 文章內(nèi)容來源于小麥苗的學(xué)習(xí)筆記，部分整理自網(wǎng)絡(luò)，若有侵權(quán)或不當(dāng)之處還請諒解
● 版權(quán)所有，歡迎分享本文，轉(zhuǎn)載請保留出處
...............................................................................................................................
拿起手機(jī)使用微信客戶端掃描下邊的左邊圖片來關(guān)注小麥苗的微信公眾號：xiaomaimiaolhr，掃描右邊的二維碼加入小麥苗的QQ群，學(xué)習(xí)最實(shí)用的數(shù)據(jù)庫技術(shù)。
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號
手機(jī)網(wǎng)站二維碼
