7. 安裝 Grid Infrastructure

安裝 Grid Infrastructure 之前，需要先做好如下準備:

1. 硬體與作業系統須符合 Grid Infrastructure 安裝需求，例如安裝 11g 的 Grid Infrastructure 要求作業系統至少為 Linux 4 update 7 以上 、 實體記憶體需 1.5G 以上 、 /tmp 空間至少 1G ；安裝 19c 的 Grid Infrastructure 至少需 Linux 7 以上 、實體記憶體需 8G 以上 、 /tmp 至少 1G 。除此之外，作業系統還必須設定符合 Grid Infrastructure 要求的 Kernel Parameters 與 RPM Packages ，這些需求每個版本不盡相同，可以參閱各版本的 Installation Guide ，或者是準備好作業系統光碟，等到安裝檢查步驟的提示再進行設定吧。 Oracle Linux 提供了 oracle-database-preinstall 這個 rpm ，我們可以簡單安裝這個 rpm 就可以符合安裝的要求。

2. 每台 Server 除了本機 IP 外，另外需規劃出一組 vip 以及 private ip ，於 DNS 上面需註冊一組 SCAN NAME 並對應三組 IP ，這邊稱作 scan ip 。 scan ip 可設定一組於 /etc/hosts 代替 DNS ，但建議上還是使用 DNS 註冊較好。本機 IP 、 vip 與 private IP 必須寫入 /etc/hosts :

127.0.0.1       loopback localhost 192.168.49.11      dbgrid01 192.168.49.12      dbgrid02 10.0.0.1     dbgrid01-priv 10.0.0.2     dbgrid02-priv 192.168.49.111      dbgrid01-vip 192.168.49.112      dbgrid02-vip

3. 須設定 Shared Disk ，所有 Server 必須要可以同時存取這些 Disk ，這個部分需要由 Storage 相關人員協助完成。設定好之後，於作業系統上需將這些 Disk 的權限更改為 Grid Infrastructure 的使用者，由於在 Linux 系統上重開機之後， Disk 的權限會變更回 root ，因此必須透過 udev rule 的設定來保持 Disk 的權限不會異動，例如於 /etc/udev/rule.d 底下建立一個 99-oracle-asmdevices.rules ， Disk 的權限應為 660 且擁有者為 grid:oinstall ， 如果有設定 asmadmin 群組，則權限應為 grid:asmadmin 。

KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/$name", RESULT=="1ATA_VBOX_HARDDISK_VB956ac525-f35825ce", NAME="asm_disk1", OWNER="grid", GROUP="oinstall", MODE="0660"

這麼一來就可以確保重開機之後的 Disk 權限不會被變更。到了 Oracle 12.2 之後多了 AFD (ASM Filter Driver) 這個新功能，這個功能會先把 Disk 格式化為 ASM Disk ，也會保護這些 ASM Disk 的表頭不會被異動，避免人為的疏失導致 ASM Disk 不可用，除此之外， AFD 也會自行設定一組 udev rule 來維持 ASM Disk 的權限。自 Oracle 19c 開始， AFD 可以透過 asmca 在建立 Disk Group 的介面進行勾選，之後在 Disk Group 建立的過程中就會自行設定了，使用了 AFD 我們就不需要再自行設定 udev rule 了。

4. 規劃好放置 OCR / Voting Disk 的 Disk Group 空間，例如以 Oracle 12.2 來說，如果 Disk Group 設定為 External Redundancy ，則需要一個 Disk 、 共 1.4G 以上； Normal Redundancy 需要 3 個 Disk 共 2.5G 以上； High Redundancy 需要 5 個 Disk 共 3.6G 以上，這邊要注意的是，在 12.2 的版本仍然是要求要建立 GIMR 的，而 GIMR 在 12.2 對於空間的要求非常大， External Redundancy 需要 37.6G ； Normal Redundancy 需要 75.5G ； High Redundancy 需要 113.4G ，如果沒有額外規劃一個 Disk Group 來存放 GIMR 的話，預設會存放在與 OCR 相同的 Disk Group 當中。

5. 建立 Grid Infrastructure 使用者，一般來說會建立一個名為 grid 的使用者，與 Database 的使用者 oracle 分開使用，也可以不區分只使用一個 oracle 使用者。 grid 這個使用者所賦予的 group 可以簡單的使用 oinstall 、 dba 就好，或者是使用完整的設定 asmadmin 、 asmoper 、 asmdba 這些群組 :

# groupadd -g 54321 oinstall # groupadd -g 54322 dba # groupadd -g 54327 asmdba # groupadd -g 54329 asmadmin # groupadd -g 54328 asmoper # useradd -u 54422 -g oinstall -G dba,asmadmin,asmdba grid # useradd -u 54421 -g oinstall -G dba,asmdba,asmoper oracle

使用者建立好之後，需設定使用者的 ulimited ，於 /etc/security/limits.conf 設定:

grid soft nproc 2047 grid hard nproc 16384 grid soft nofile 1024 grid hard nofile 65536 oracle soft nproc 2047 oracle hard nproc 16384 oracle soft nofile 1024 oracle hard nofile 65536

6. 設定 Server 之間的 ssh authorization ，安裝過程中會使用 ssh 將軟體複製安裝到所有的節點之上，因此設定 ssh authorization 是必須的，這個部分可以在安裝前自行先設定好，或者是透過 Grid Infrastructure 的安裝步驟來幫助我們設定。

dbgrid01$ /home/grid>ssh-key_gen -t rsa dbgrid01$ /home/grid>ssh-key_gen -t dsa dbgrid02$ /home/grid>ssh-key_gen -t rsa dbgrid02$ /home/grid>ssh-key_gen -t dsa (於兩台 Server 分別設定 ssh key) dbgrid01$ /home/grid/.ssh>cat id_rsa.pub >> authorized_keys dbgrid01$ /home/grid/.ssh>cat id_dsa.pub >> authorized_keys dbgrid01$ ssh dbgrid02 cat ~/.ssh/id_rsa.pub >> authorized_keys dbgrid01$ ssh dbgrid02 cat ~/.ssh/id_dsa.pub >> authorized_keys dbgrid01$ scp authorized_keys dbgrid02:~/.ssh (將兩台的 ssh key 加入並複製到另外一台) dbgrid01$ ssh dbgrid01 date dbgrid01$ ssh dbgrid02 date dbgrid02$ ssh dbgrid01 date dbgrid02$ ssh dbgrid02 date (確認 ssh authorization 設定是否成功)

7. 設定 NTP ，如果沒有使用 NTP ， Grid Infrastructure 有 ctss 這個 Daemon 來對 RAC 節點之間互相進行教時。

在準備好前置作業後，接下來就可以正式安裝 Grid Infrastructure ，準備好 XWindows 工具後，使用 grid 使用者於 Grid Infrastructure 的軟體目錄下執行 runInstaller 叫出安裝介面，在 Oracle 12.2 版本之後有所不同， 12.2 版本之後的軟體已經是包裝成完整的 Grid Home ，因此 12.2 之後必須把軟體解壓縮至要安裝的路徑底下，例如要安裝在 /u01/app/12.2.0/grid ，那麼就必須把軟體解壓縮至這個路徑底下，然後再執行 grid_setup.sh 呼叫出安裝介面。

這邊選擇 Configure Grid Infrastructure for a Cluster 進行 RAC 的安裝，在 12c 的版本之後，進一步的選擇 Configure an Oracle Standalone Cluster 作為 RAC 標準架構的安裝。

接下來就是要為這組 RAC 設定一個名稱 Cluster Name ， Cluster Name 可以依自己的喜好進行命名； SCAN NAME 則是先前於 DNS 上面所註冊的名稱 ； SCAN PORT 則是設定將來 SCAN Listener 所用的 Port Number ，預設為 1521 :

如果沒有使用 GNS 架構，那麼 Configure GNS 這個部分不需要進行設定。

接下來要把需要安裝節點的 Server 成員加入設定，這邊要求節點間的 ssh 能夠互相信任溝通，如果沒有在前置作業先行設定 ssh authorization 的話，這邊也可以點選 ssh connectivity 讓系統自行幫我們進行設定:

12c 版本以上多了 HUB Node 與 LEAF Node 的概念， LEAF Node 代表可以不用直接存取 Shared Stroage 的節點，這邊標準安裝我們節點都是選擇 HUB Node 。

下一個步驟設定對外 Public 的網卡名稱以及網段，與對內 Private 的網卡名稱及網段:

在 12c 之後的版本，對內的網卡要選擇 ASM & Private 。

接下來要選擇所使用的 Storage Type ，建議使用 ASM :

如果是安裝 19c ，這邊可以選擇是否要建立 GIMR ，早期 Grid Infrastructure 安裝會自動建立 GIMR ，也就是會在 ASM 裡面建立一個名為 –MGMTDB 的 DB ，用途是用來存放 Cluster Health Monitor 與作業系統的監控資訊，在 19c 的版本可以選擇不要使用 GIMR ，因為如果要監控作業系統資訊，可以使用 OSWatcher 等工具，不需要經由 GIMR 來蒐集:

接下來要先建立一個 Disk Group 來存放 OCR ，這個步驟當中，在 19c 可以勾選是否使用 AFD :

之後使用 asmca 建立其它的 Disk Group 也可以勾選 AFD 來使用:

接下來的幾個步驟就是簡單的設定 ASM Instance 的 sys 使用者密碼、 ASM 管理者的作業系統群組，以及 Grid Infrastructure 的安裝路徑:

從 12c 之後，這邊可以選擇安裝過程中是否自動執行 root.sh 腳本，如果要讓系統自動執行的話，這邊需要提供 root 使用者的密碼:

接下來會進行安裝前檢查，如果有 RPM 未安裝以及相關 Kernel Parameter 沒有設置妥當的話，這邊會進行提示:

Fix & Check Again 按鈕可以讓系統自動幫我們修復 Kernel Parameter 與使用者 ulimited 的相關設定，這邊要注意的是，如果是修復使用者的 ulimited 設定，那麼修正後必須重新啟動這個安裝介面，系統檢查才會通過。不過有些檢查是無法讓系統自動修復的，例如有 RPM 未安裝，那麼此時就必須要自行安裝這些缺少的 RPM 才行。

安裝的最後一個步驟，系統會提示我們使用 root 使用者於每一個節點上執行 root.sh 腳本:

執行完 root.sh 之後別忘了返回繼續讓系統做完後續的設定:

最後的設定檢查結束後，便完成了 Grid Infrastructure 的安裝。

安裝完成後，可以使用 crsctl stat res –t 檢查相關服務是否正常:

安裝完 Grid Infrastructure 之後，接下來就可以在基於 RAC 的架構下安裝 Oracle Database 軟體，一般來說， Oracle Database 軟體的版本會與 Grid Infrastructure 相同，如果有不同版本的需求，那麼 Oracle Database 軟體的版本不可以大於 Grid Infrastructure ，例如 Grid Infrastructure 安裝的是 12c ，那麼 Oracle Database 軟體就只能安裝 12c 或是 12c 以下的版本。

基於 RAC 架構下的 Oracle Database 軟體安裝與一般的安裝過程沒有特別的差異，只有在一開始的時候需要將 RAC 所有的節點選入進來即可:

後續的步驟就不再贅述。

安裝完 Oracle Database 軟體之後，接下來就可以建立 RAC 資料庫，建立資料庫之前，可以先使用 asmca 建立資料庫所需的 Disk Group 。資料庫的建立一樣是使用 DBCA ，建立過程與建立一般 DB 沒有差異，只有一開始的時候需要將所有的節點選入進來:

在 RAC 架構下，資料庫的 SID 會自動加上編號，這邊只需設定 SID Prefix ，之後實際的 SID 會自動加上號碼，例如這邊 SID Prefix 設定的是 RDBA ，那麼建立好之後，節點一的 SID 就會是 RDBA1 ；節點二的 SID 則是 RDBA2 。

安裝至此，可以說是建立好了一套完整的 RAC 架構資料庫。

6. 管理 ASM

ASM 在管理上可以使用 SQL*Plus 、 ASMCA ，與 ASMCMD 。透過 SQL*Plus 可以直接進入 ASM Instance 進行管理，指定 ORACLE_SID 為 +ASM1 (RAC 第一個 node 的 ASM Instance) 並以 sysasm 權限進入:

$ export ORACLE_SID=+ASM1 $ sqlplus / as sysasm SQL>

進入後就與一般的 Database Instance 操作無異，可以進行查詢、修改參數…等，對於 ASM Instance 來說，最高權限為 sysasm 而非 sysdba ，使用 sysdba 進入後有些操作會無法進行，例如 create diskgroup 就無法使用 sysdba 進行操作。 ASM Instance 當中比較會異動到的參數為 asm_diskstring 與 asm_power_limit ， asm_diskstring 是用來設定讀取 ASM Disk 的路徑，目的是要讓 ASM Instance 知道 ASM Disk 所在的位置，例如 ASM Disk Group 是由 /dev/sda 、 /dev/sdb …等 Disk 所組成，那麼 asm_diskstring 就會設定為 /dev/sd* ； asm_power_limit 是用來設定 ASM Disk Rebalance 的速度，預設為 1 表示最慢，最大可設置為 11 ，如果 ASM Disk Group 的 COMPATIBLE.ASM 屬性設置為 11.2.0.2 以上，則 asm_power_limit 最大可為 1024 ，當有 ASM Disk 新增或移除時， ASM Disk Group 便會進行 Rebalance 的動作，希望它 Rebalance 越快完成， asm_power_limit 就可以設置大一點，然而 Rebalance 越快也代表者需要消耗較多的 I/O 資源在 Rebalance 作業上，對效能具有一定的影響。

進入到 ASM Instance 除了參數的設定外，最常做的就是檢查 ASM Disk Group 與 ASM Disk 的狀態，這些可以透過 v$asm_diskgroup 、 v$asm_disk 與 v$asm_attribute 來進行查詢，例如檢查 ASM Disk Group 的狀態、可用空間…等，就可以使用 v$asm_diskgroup 來查詢:

如果要知道目前 Disk Group 有哪些 ASM Disk 以及是否有可用的 ASM Disk ，則是透過 v$asm_disk 來查詢:

v$asm_attribute 則是用來查詢每個 Disk Group 的屬性，其中比較重要的屬性是 compatible.asm 、 compatible.rdbms 與 disk_repair_time :

compatible.asm 用來設置能夠使用此 Disk Group 的 ASM Instance 最低版本，例如 compatible.asm 設置為 10.1 ，那麼就表示 Oracle 10g 以上版本的 ASM Instance 都可以使用此 Disk Group ，如果 compatible.asm 設置為 11.2 ，那麼由 Oracle 10g 所啟動的 ASM Instance 就無法存取此 Disk Group ，必須要 Oracle 11g 以上版本的 ASM Instance 才可以存取； compatible.rdbms 表示能夠使用此 Disk Group 的資料庫最低版本，例如 compatible.rdbms 設置為 11.2.0 ，那麼只有在 Oracle 11R2 以後版本的資料庫才可以把 Data File 放置在此 Disk Group 當中； disk_repair_time 表示 Disk Group 可容許 ASM Disk 遺失的時間，例如有實體的硬碟損壞，那麼在 Disk Group 當中便會看到此 ASM Disk 狀態為 OFFLINE ， ASM 會暫時保留這個 ASM Disk 在 Disk Group 裡面，如果超過了 disk_repari_time 的設定時間還沒有修復好這個損壞的 Disk ，那麼 ASM Disk Group 才會把這個遺失的 Disk 正式移出 Disk Group 。要修改 Disk Group 屬性可以透過 alter diskgroup set attribute 指令修改，例如將 disk_repair_time 修改為 24h :

SQL> alter diskgroup data set attribute 'disk_repair_time' = '24h';

這邊要注意的是，不是每個 attribute 都可以隨意更改，像是 compatible 屬性只能往上調整不能往下調整，例如 compatible.rdbms 已經設置為 11.2.0 就不能修改為 10.1 ，假設此時還有 Oracle 10g 的資料庫存在，那麼就會變得無法使用，因此修改此參數必須謹慎；有些 attribute 是在 Disk Group 建立後就無法更改，例如 au_size ，如果嘗試修改的話便會報錯:

ASMCA 是一個圖形化介面的工具，可以用來新增刪除 Disk Group 、幫 Disk Group 添加或移除 ASM Disk ，以及建立 ACFS 。設定好 XWindow 工具之後執行 asmca 便可以使用，例如新增一個 Disk Group 只需點選 create 以及選擇要加入的 ASM Disk 即可:

透過 asmca 來建立一個 ACFS 也是相當的方便，首先由一個 Disk Group 建立出一個 Volume :

再由此 Volume 建立出 ACFS 即可:

不同版本下的 asmca 介面略有不同，但整體的操作方式是一樣的。

ASMCMD 是一個 command line tool ，由於 ASM Disk Group 不會顯示在作業系統上面，無法使用作業系統的命令來檢視 Disk Group 的內容與狀態，而 ASMCMD 就是用來檢視 ASM Disk Group 所用，首先須設定好 ORACLE_HOME 為 Grid Infrastructure 的安裝目錄， ORACLE_SID 為 +ASM1 ，然後直接執行 asmcmd 就會進入 ASMCMD> 的介面底下，在 ASMCMD> 底下就可以使用作業系統般的指令來檢視 Disk Group 的內容，例如 ls 、 cd …等指令都可在 ASMCMD> 底下執行:

早期 ASM 剛推出的時候，由於在作業系統上不可見，常常被詬病為黑盒子，但有了 asmcmd 這項工具後，檢視 Disk Group 的內容便可以一目了然，在管理上添加了許多便利性。

進入到 asmcmd 以後，可以簡單的執行 lsdg ，這個命令會列出所有 Disk Group 的狀態與可用空間，其實內容就與查詢 v$asm_diskgroup 的內容一樣，只不過透過 asmcmd 查詢更加方便:

其中 Total_MB 表示整個 Disk Group 的總空間； Free_MB 表示整個 Disk Group 剩餘的可用空間，這裡不計算冗餘； Req_mir_free_MB 表示當有 Disk 損壞時，剩下的 Disk 需要保留多少空間才可以維持冗餘的水準； Usable_file_MB 表示在計算有 Disk 損壞的情況下，還能夠維持冗餘水準的可用空間。例如一個 Normal Redundancy 的 Disk Group DATADG ，裡面總共設定三個 Failure Group (FG1，FG2，FG3) ，每個 Failure Group 都有兩顆 Disk ，每個 Disk 100G :

以上 Total_MB 為 600G ；假設已經使用了 50G ，那麼此時的 Free_MB 就為 550G ； Req_mir_free_MB 會從寬計算，會以最大的 Failure Group 大小作為計算值，因此這邊的 Req_mir_free_MB = 200G ，也就是說當有 Disk 損壞時，剩下的可用空間必須要大於 200G 才能夠保持兩份的 Normal Redundancy 冗餘； Usable_file_MB 表示安全可用空間，也就是說在計算當有 Disk 損壞時還能夠保持兩份冗餘的情況下的可用空間，因此這邊的 Usable_file_MB = (Free_MB - Req_mir_free_MB) / 2 (Normal Redundancy 可用空間要除以 2) = (550 – 200)/2 = 175G 。

由於 Usable_file_MB 是在預先考量有 Disk 損壞的情況下所計算出來的，因此當 Free_MB 小於 Req_mir_free_MB 的時候， Usable_file_MB 就會出現負值，此時並不代表空間不足夠，只是說當有 Disk 損壞時無法維持冗餘的水準，如果 Disk Group 的空間足夠的話，建議平時還是維持安全可用空間的水準 (Usable_file_MB > 0) 。

由於 ASM 的架構不同於一般的檔案系統，因此剛推出的時候會讓人覺得陌生，不過經由這些工具的輔助，相信 DBA 也會對這項功能越來越熟悉，管理起來會更得心應手。

5. Oracle ASM 架構

Oracle ASM (Automatic Storage Management) 是從 Oracle 10g 開始推出的新功能，為了用來搭配 RAC 所使用的一種存儲結構，有了 ASM 之後，搭建 RAC 就不再需要第三方的 Cluster File System ，自此 Oracle 便擁有了一套完整的 Cluster 架構。 ASM 一開始於 Oracle 10g 推出的時候，是歸於 Database Home 底下進行管理，而從 Oracle 11g 之後， ASM 就屬於 Grid Infrastructure 的一部分了。

傳統磁碟的使用方式是將磁碟做成 Volume ，然後再將其 Format 成 File System 並掛載在作業系統上，之後就可以存放檔案了；而 ASM 則是完全取代了這一部分，這個部分以 ASM 的 Disk Group取代之，檔案存放在 ASM 的 Disk Group 裡面。

ASM Disk Group 是一種邏輯的存儲概念，一個 Disk Group 由一個或多Disk 所構成，有點類似 Tablespace 與 Data File 這種邏輯與實體結構 :

對於 Oracle 資料庫的邏輯結構來說，底層的 Physical block 會 Format 成 Oracle Block ，多個 Oracle Block 構成 Extent ，多個 Extent 構成 Segment ，最上層的 Tablespace 則是由實體的 Data File 所構成；對於 ASM 來說，首先將實體的 Disk 格式化為 ASM Disk ，一個或多個 ASM Disk 組成一個 Disk Group ，在 Disk Group 裡面存放的檔案稱作 ASM File ，而 ASM File 裡面又可以劃分多個 Allocation Unit (AU) ， AU 則是由底層的 Physical Block 所構成。

ASM 的 Allocation Unit (AU) 在建立 Disk Group 的時候就必須決定每個 AU 的大小，在 Oracle 10g 的時候 AU 預設為 1M ，到了 Oracle 12c 之後預設則為 4M ，也是比較建議的大小。一個 ASM File 是由多個 AU 所組成，而 ASM 的特性是會將這些 AU 平均分散在每個 ASM Disk 上面，如果有 ASM Disk 新增或者是移除，它也會動態的平衡 (Rebalance) 到這些新增或者是移除所剩下的 ASM Disk 上面，這個行為有點類似 Storage 的 RAID 0 結構。

ASM 除了動態平衡的特性之外，也可以為 AU 設置冗餘，用途是為了避免當 ASM Disk 損壞時造成資料的遺失，冗餘必須在 Disk Group 建立時決定是否設置， External Redundancy 表示不設置冗餘，所有的 AU 都只有一份 ； Normal Redundancy 表示每一個 AU 都維持兩份， High Redundancy 表示每一個 AU 都複製成三份。當有冗餘設置時，在一個 ASM Disk Group 裡面必須再劃分 Failure Group ， Failure Group 的用意在於每一個 AU 的 copy 必須存放在不同的 Failure Group 上面，這樣當一份損毀時，還有另外一份可以用。 Failure Group 的概念就是將一個 ASM Disk Group 裡面的 ASM Disk 進行分組，每一個 AU 的 copy 必須存放在不同組別上，這樣才有保護的作用，在 Normal Redundancy 架構下必須劃分兩個 Failure Group 以上； High Redundancy 則是要劃分三個 Failure Group 以上， Normal Redundancy 可以容許一個 Failure Group 完全損壞，因為所有的 AU 都保留兩份，損壞了一份還有一份可用，同理 High Redundancy 則是可以容許兩個 Failure Group 損壞，如果在建立 Disk Group 時沒有自行將 ASM Disk 分組為 Failure Group ，則預設一個 ASM Disk 自己會做為一個 Failure Group 所使用，例如一個 ASM Disk Group 裡面有四個 ASM Disk ，如果沒有指定哪些 ASM Disk 屬於哪個 Failure Group ，則這四個 ASM Disk 自己都會是一個 Failure Group ，也就是總共會有四個 Failure Group 。 ASM 這種冗餘的概念，有點類似 Storage 的 RAID 1 結構，但不同的是， RAID 1 是 Disk 對 Disk 做 Mirror ，而 ASM 則是以 AU 為單位作為 Mirror ，每一個 AU 的 Primary copy 與 Secondary copy 不一定是在哪個 ASM Disk 上面，可以確定的是，它們只會屬於不同的 Failure Group 。

ASM Disk Group 是由 ASM Disk 所組成，而 ASM Disk 則是由實體的 Disk 格式化成 ASM Disk 而來，實際上 ASM 只會識別作業系統上面所提供的 Disk 名稱，作業系統上面的 Disk ，底層可能是沒有經過分割的裸磁碟，或者是透過 Storage 做成 RAID 之後所形成的 Disk ，這些都可以用來作為 ASM Disk 所用，因此在冗餘的選擇上，底層可以選擇使用裸磁碟，然後只使用 ASM Disk Group 層面的 Normal 或 High Redundancy ；或者是底層已經使用冗餘 (例如 RAID 1+0) ，然後在 ASM Disk Group 層面不使用冗餘 (External Redundancy) ，這兩者都具有資料保護的作用。

ASM 的使用上，必須啟動 ASM Instance ， ASM Instance 啟動之後所有的 Disk Group 才可以使用，在 Oracle 10g 的時候， ASM 屬於 Database Home 所管理，所以 ASM Instance 需要透過 DBCA 來額外建立，從 Oracle 11g 以後， ASM Instance 屬於 Grid Infrastructure 的一部分，要使用 ASM 必須要安裝 Grid Infrastructure ， ASM Instance 屬於 CRS 的一部分， ASM Instance 跟隨著 CRS 一起啟動，在 ASM Instance 啟動之後， ASM 本身會產生 RBAL 、 ARBn 與 GMON 三個 Background Process :

ASM Instance 的 RBAL process 是用來管理 ASM Disk Rebalance 所用，也就是一個 Rebalance Coordinate Process ； ARBn 則是實際上執行 Disk Rebalance 的 Process ； GMON 為 Disk Group Monitor Process ，用來監控 ASM Disk ，例如新增或刪除 ASM Disk ，或者是 ASM Disk Online 、 Offline 狀態…等。對於 Database Instance 來說，如果要將 Data File 放置於 ASM ，則必須透過 ASMB 與 RBAL 兩個 Process ， ASMB 是 Database Instance 用來與 ASM Instance 連線所用，也就是這兩種 Instance 之間溝通的橋樑； RBAL 則是 Database Instance 用來存取 ASM Disk 所用，也就是 Database Instance 與 ASM Disk 之間溝通的橋樑。將 Data File 建立於 ASM 只需簡單的指定 Disk Group 名稱，裡面的檔案均以 OMF 命名，好處是不用特別管理 ASM File ，或者是直接指定 Data File 的名稱也可以，只不過這個名稱對於 ASM 來說只是一個別名，其實底層還是有一個 OMF 的檔案存在:

SQL> create tablespace asm_tbs datafile '+DATADG' size 512M;       (建立 Tablespace 至 ASM 的 DATADG ，以 OMF 命名) SQL> create tablespace asm_tbs datafile '+DATADG/ORCL/asm_tbs01.dbf' size 512M;       (建立 Tablespace 至 ASM 的 DATADG ，自行命名為 asm_tbs01.dbf)

我們除了可以將 Data File 放置在 ASM Disk Group 當中，也可以將其放置在 ACFS 上， ACFS (ASM Cluster File System) 是一種建立在 ASM 結構之上的一種 File System 架構， ASM Disk Group 實際上是一種直接存取 Disk 的架構，並不是像傳統在作業系統上面可以看到的一種 File System ， ASM Disk Group 在作業系統上是無法看到的，必須透過 Oracle 的指令來進行查詢，而 ACFS 則是 ASM 一種進階的運用，基於 ASM Disk Group 將其劃分出 Volume ，然後將其格式化之後掛載到作業系統上面，這樣作業系統就可以看到一個 File System 掛載在上面，這個 File System 就稱作是 ACFS ，差別只在於 ACFS 是由 ASM Disk Group 所劃出的 Volume 而來，而一般的 File System 則是由傳統的 Disk Volume 所產生出來，除此之外， ACFS 是一種 Cluster File System ，必須是在 Cluster (RAC) 架構下才可以使用。另外 ACFS 與原始的 Disk Group 差別在於， ASM Disk Group 只能存放 Oracle 相關的檔案，例如資料庫的 Data File 、 Archive Log 、 RMAN 備份 ， expdp 的 dump 檔…等，而 ACFS 則是在作業系統上可見的 File System ，與一般的檔案系統無異， ACFS 可以放置任何的檔案。

對於 Disk Group 的規劃，一般建議建立兩個 Disk Group ，一個為 DATADG ，用來放置資料庫的 Data File ，另一個為 RECODG ，用來放置資料庫的 Redo Log 與 Archive Log ，除此之外，可以獨立建立一個 SYSTEMDG 專門來放置 Grid Infrastructure 的 OCR 與 Voting Disk，這些不一定要建立單獨 Disk Group 來存放，可與 DATADG 放置在一起，唯一要注意的是，放置 OCR 與 Voting Disk 的 Disk Group ，如果設置為 Normal Redundancy ，那至少要設定三組以上的 Failure Group ； 如果為 High Redundancy ，那麼至少要設定五組以上的 Failure Group 。