第二部分 平臺

第4章 Grid 的五臟六腑

在這一章中，我們會把 Grid 放在放大鏡下仔細地剖析，這一章的內容并不有趣，很枯燥乏味，對我來說也是這樣，因此，請讀者朋友做好準備。我建議讀者朋友對文字內容做泛讀，不要強迫自己去記住多少，把重點放在本章中的幾幅圖上，以后有需要時再回過頭來詳讀相應的章節。

在這一章中，我們繼續對比圖4-1和圖4-2的不同，以此來展開說明。

圖4-1 Oracle Clusterware 10g的架構圖

圖4-2 Oracle Grid 11g R2的架構圖

先說明一下，從Oracle Clusterware 到Oracle Grid，這其中的變化不是顛覆性的，而是改善性的。它倆比起來，Clusterware就是一個未經修飾的原生態，只有最核心的功能、樸素的外表，沒有任何花哨的包裝。而Grid就是個經過包裝的、看起來更加精美的玩意。核心功能、算法還是原來那一套，只是被外面這層華麗的包裝給掩蓋住了，會讓人誤以為又是個全新的東西了。

所有Oracle Clusterware中的內容在Grid中仍然存在，Grid的基礎仍然是原來Clusterware提供的三大服務，引入的變化包括：

層次化；

Agent的管理方式；

更豐富的資源；

啟動順序的變化。

下面我們分別介紹這些變化。

4.1 層次變化

Oracle Grid 11.2對原來的Clusterware重新架構，原來的CRS被拆成了兩部分，分成了兩個棧。在官方文檔中，這兩個棧分別叫做CRSD棧（Cluster Ready Service Daemon）和OHASD棧（Oracle High Availability Service Daemon），前者負責上層高級別的資源（Higher Level Resource），比如數據庫實例，而后者負責下層低級別（Low Level）進程，因此也有Upper Stack和Lower Stack的叫法，我這里遵循的是Oracle文檔的術語。

配合著CRS的拆分，CRS的配置信息OCR也被拆分成了兩部分，分別是OLR和OCR。其中OHASD管理的是OLR，而CRSD管理的是OCR。

OHASD進程是整個Oracle進程堆棧的基礎，它根據/etc/oracle/scls_scr/<hostname>目錄下的控制文件的內容決定其他堆棧成員的狀態，這些文件內容不可以手工修改。另外，ohasd 還會使用一個有名管道，位于/var/tmp/.oracle目錄下，而其他進程使用的管道也是放在這個目錄下。因此在集群運行過程中不可以清理這個目錄。

OHASD管理的daemon可以和其他節點上的對應進程相互通信。只要OHASD啟動，這個節點就可以加入到集群中，而且可以使用那些共享元素（比如 OCR）。OHASD 棧的啟動順序記錄在GPnP profile中，也依賴于OLR中的信息。

CRSD現在更專注于上層（應用層）資源的維護。區分這兩種級別的資源也很簡單，通過關閉CRS的輸出內容中就可以看出來，先于CRSD關閉的那些資源就是上層資源，而CRSD之后再關閉的資源就全部是OHASD的資源了。來看下面的輸出內容：

[root@indexserver2 ～]# /u01/app/11.2.0.2/grid/bin/crsctl stop crs

CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on'indexserver2'

CRS-2673: Attempting to stop 'ora.crsd' on 'indexserver2'

CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on 'indexserver2'

CRS-2673: Attempting to stop 'ora.DATA.dg' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.registry.acfs' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.oc4j' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.cvu' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.LISTENER.lsnr' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.LISTENER_SCAN3.lsnr' on 'indexserver2'

CRS-2677: Stop of 'ora.cvu' on 'indexserver2' succeeded

CRS-2672: Attempting to start 'ora.cvu' on 'indexserver1'

CRS-2677: Stop of 'ora.LISTENER.lsnr' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.indexserver2.vip' on 'indexserver2'

CRS-2677: Stop of 'ora.LISTENER_SCAN3.lsnr' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.scan3.vip' on 'indexserver2'

CRS-2677: Stop of 'ora.scan3.vip' on 'indexserver2' succeeded

CRS-2672: Attempting to start 'ora.scan3.vip' on 'indexserver1'

CRS-2677: Stop of 'ora.indexserver2.vip' on 'indexserver2' succeeded

CRS-2672: Attempting to start 'ora.indexserver2.vip' on 'indexserver4'

CRS-2676: Start of 'ora.cvu' on 'indexserver1' succeeded

CRS-2677: Stop of 'ora.registry.acfs' on 'indexserver2' succeeded

CRS-2676: Start of 'ora.indexserver2.vip' on 'indexserver4' succeeded

CRS-2676: Start of 'ora.scan3.vip' on 'indexserver1' succeeded

CRS-2672: Attempting to start 'ora.LISTENER_SCAN3.lsnr' on 'indexserver1'

CRS-2676: Start of 'ora.LISTENER_SCAN3.lsnr' on 'indexserver1' succeeded

CRS-2677: Stop of 'ora.oc4j' on 'indexserver2' succeeded

CRS-2672: Attempting to start 'ora.oc4j' on 'indexserver3'

CRS-2676: Start of 'ora.oc4j' on 'indexserver3' succeeded

CRS-2677: Stop of 'ora.DATA.dg' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.asm' on 'indexserver2'

CRS-2677: Stop of 'ora.asm' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.ons' on 'indexserver2'

CRS-2677: Stop of 'ora.ons' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.net1.network' on 'indexserver2'

CRS-2677: Stop of 'ora.net1.network' on 'indexserver2' succeeded

上面這些就是CRSD層維護的資源。

CRS-2792: Shutdown of Cluster Ready Services-managed resources on 'indexserver2' has completed

下面這些就是OHASD層維護的資源。

CRS-2677: Stop of 'ora.crsd' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.ctssd' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.evmd' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.asm' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.mdnsd' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.drivers.acfs' on 'indexserver2'

CRS-2677: Stop of 'ora.asm' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.cluster_interconnect.haip' on 'indexserver2'

CRS-2677: Stop of 'ora.evmd' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.drivers.acfs' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.cluster_interconnect.haip' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.mdnsd' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.ctssd' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.cssd' on 'indexserver2'

CRS-2677: Stop of 'ora.cssd' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.diskmon' on 'indexserver2'

CRS-2673: Attempting to stop 'ora.crf' on 'indexserver2'

CRS-2677: Stop of 'ora.crf' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.gipcd' on 'indexserver2'

CRS-2677: Stop of 'ora.diskmon' on 'indexserver2' succeeded

CRS-2677: Stop of 'ora.gipcd' on 'indexserver2' succeeded

CRS-2673: Attempting to stop 'ora.gpnpd' on 'indexserver2'

CRS-2677: Stop of 'ora.gpnpd' on 'indexserver2' succeeded

CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'indexserver2' has completed

CRS-4133: Oracle High Availability Services has been stopped.

4.2 基于Agent的管理方式

在Oracle 11.2之前，Clusterware對于資源的管理、監控都是通過RACG腳本方式進行的，每當Clusterware要啟動、關閉、檢查一個資源時，就會調用這些腳本，傳入相關的參數（start、stop、check）即可。

從Oracle 11.2開始出現了多用戶的概念，Oracle開始使用一組多線程的daemon來同時支持多個用戶使用、管理這些資源，這些daemon就叫做Agent。這些Agent都是一些常駐內存的進程，因為常駐在內存中，所以可以進行更加快速的故障檢查以及更加快速的恢復。比如，對于Oracle監聽器來說，平均的故障恢復時間從原來的5分鐘縮短到了30秒，而檢查的頻率也由原來的10分鐘一次增加到1分鐘一次。這些Agent本身是由OHASD和CRSD以spawn方式啟動的，可以管理更多的資源。

Agent 這種框架可以支持用 C、C++、腳本等多種語言的插件，因此可以按自己的喜好來開發、管理所有資源。這種管理方式也叫做Agent-Based管理系統。

1．Agent的分類

Oracle Grid 11.2的Agent有多個，其中有兩個最重要，分別是Oracle Agent和Oracle Root Agent。這兩種Agent的區別就在于維護資源所使用的身份不同。

Oracle Agent就是以Oracle用戶身份運行（這個Oracle用戶是一個泛指，根據場合的不同可能是Grid，也可能是Oracle），Oracle Root Agent是以root身份運行的。

這兩個Agent對應的操作系統進程名字分別是orarootagent、oraagent。在Grid 11.2環境中，不管是Oracle Agent還是Oracle Root Agent都不止一個，而是多個，或者說多套。

OHAS棧會啟動一套Oracle Agent和Oracle Root Agnet，由OHAS啟動的Oracle Agent是用Grid的安裝用戶（通常是grid）身份運行的。

CRS棧也會啟動一套Oracle Agent和Oracle Root Agent，這個Oracle Agent是以Oracle身份運行的，如果Grid不是用oracle用戶安裝的——大部分情況下都不是——CRS棧還會啟動第3套Oracle Agent，這套Oracle Agent是以Grid身份運行的

這兩類Agent對應的進程名字都是orarootagent、oraagent。它們有各自的日志文件，這些Agent的日志文件位于：

$GRID_HOME/log/<hostname>/agent/{ohast|crsd}/<agentname>_<owner>/<agentname>_<owner>.log

比如，ora.crsd是由OHASD管理的，屬于root用戶，因此Agent的名字是orarootagent，于是對應的日志就是：

$GRID_HOME/log/<hostname>/agent/ohasd/orarootagent_root/orarootagent_root.log。

同一個 Agent 日志文件中可以記錄來自于多個源的日志，前提條件是這些源是由同一個Daemon、同一個Agent、同一個用戶管理的。

這兩個 Agent 是最主要的 Agent，此外還有專門負責管理和監視 CSSD 的 Agent，叫做cssdmonitor 和 cssdagent。這兩個 Agent 也是由 OHAD 啟動的。還有一種 Script Agent，這種Agent是供用戶插入自定義資源使用的。比如我們后面會演示用Grid維護第三方資源，那里用到的就是Script Agent。

2．OHASD的Agent

由OHASD進程啟動的Agent統稱為OHAS Agent，它包括了4種：orarootagent、oraagent、cssdagent和cssdmonitor。這一組Agent的主要功能就是對Clusteware的進程進行監控。

由OHASD啟動的Oracle Agent是以Grid用戶（grid）的身份運行的，它是作為OHAS啟動過程的一部分由OHASD直接啟動的，這個Agent負責啟動那些不需要root權限的資源和進程，這些進程和資源包括：

EVMD和EVMLOGGER；

Gipc daemon；

Gpnp daemon；

mDNS daemon；

ASM。

由OHAS啟動的Oracle Root Agent負責啟動那些需要root權限的資源和進程，包括：

CRS daemon；

CTSS daemon；

Disk monitor daemon；

ACFS驅動。

3．CRSD的Agent

由CRSD啟動的Agent統稱為CRS Agent，它包括oraagent和orarootagent。這一組Agent的功能是對CRS資源進行監控。

對ASM的監控是OHAS Agent的任務，而對數據庫資源的監控則是CRS Agent的任務了。

一旦CRS被啟動了，CRS就會創建另一個Oracle Agent和Oracle Root Agent，如果安裝Grid的用戶不是oracle而是grid，還會創建第二個Oracle Agent。這個grid的Oracle Agent負責：

啟動并監視本地的ASM實例；

ONS和eONS daemon；

SCAN Listener；

Node Listener。

而oracle的Oracle Agent只負責啟動數據庫資源，包括數據庫實例和服務。當然，如果Grid的安裝用戶也是oracle，這個Agent同樣也會負責grid Oracle Agent的任務（前面已經列出的）。

Oracle Root Agent則負責創建GNS（如果配置了的話）、GNS VIP（如果啟用了GNS的話）、ACFS Registry、Network、SCAN VIP和Node VIP這些資源。

以上這些復雜的關系可以總結為圖4-3。圖4-3就是Agent和資源之間的樹狀關系圖。

圖4-3 Agent關系示意圖

在 Grid 11.2 中，Oracle Agent 提供的功能對應著 Clusterware 10.2 版本中的 racgmain 和racgimon兩個后臺進程的功能（這兩個進程是RACG體系的一部分）。

4.3 更豐富的資源

Oracle Grid 11.2所維護的資源比Oracle Clusterware要豐富得多，而所謂資源其實就是一堆進程，我們把這些進程梳理一下。

4.3.1 ohasd

ohasd這個進程是由/etc/init.d/ohasd腳本啟動的，這個腳本能接收start、stop兩個參數。ohasd也是在rc過程中會調用的進程。

4.3.2 ohasd 的 oraagent

ohasd的oraagent是以Grid用戶身份運行的，由它維護的資源有以下幾項。

1．ora.asm

ASM必須要先于CRSD啟動，這樣CRSD才能訪問ASM。因此ohasd負責啟動、關閉、監視ASM實例。

2．ora.evmd

EVM負責訂閱集群環境中事件的生成和發布。EVMD會產生一個叫evmlogger的子進程，再由這個進程產生更多的子進程。evmlogger進程會根據$GRID_HOME/evm/admin/evmlogger.conf配置文件產生日志，可以使用這個文件中的maxsize參數來控制日志文件的大小。

EVMD 的另一個功能就是調用用戶的回調腳本，用戶把這些腳本放在特定的 RACG 目錄下，EVMD會掃描這個目錄并負責調用這些腳本。

EVMD是以Grid身份運行的，會在失敗時自動重啟。它的日志文件位于$GRID_HOME/log/hostname/evmd/evmd.log。

3．ora.mdnsd

MDSN即Multicast DNS，它與GNSD合作來提供域名解析工作。

Oracle Grid 11.2引入了SCAN，簡單地說，SCAN就是一種域名訪問機制，就像我們只需要知道www.google.com這個域名就能訪問谷歌一樣，通過Grid的域名SCAN就能訪問Grid的數據庫。但這個域名也需要進行解析，轉換成一個IP地址才行。

解析有兩種方式，一種是通過通用的域名解析機制即 DNS，另一種是就是 Oracle 自己提供的GNS。

可以把GNS想象成Oracle專為Grid量身定做的域名解析機制，它不能對Grid之外的域名解析。它的日志文件為$GRID_HOME/log/hostname/mdnsd/mdnsd.log。

4．ora.gpnpd

GPNPD即Grid Plug and Play Daemon，這個進程負責集群節點間GPnP profile的同步。這個文件保存在每個節點的本地，位置是$GRID_HOME/gpnp/profile/peer/profile.xml。

這是一個XML文件，該文件中的內容是這個節點加入集群所需要的必需信息。它的日志文件位于$GRID_HOME/log/hostname/gpnpd/gpnpd.log。

5．ora.gipcd

在以前的版本中，集群使用TCP進行通信協議，和RDBMS的通信協議完全一樣。

從Oracle Grid 11.2開始，Oracle使用一個全新的代碼完成集群的通信協議，叫做Grid IPC以及 Grid Inter Process Communication Daemon（GIPCD）。Grid IPC 支持多種通信協議類型，包括 UDP、IPC、TCP 及 Grid IPC 本身。它的日志位于$GRID_HOME/log/hostname/gicpd/gicpd.log。

4.3.3 ohasd 的 orarootagent

這個進程是以root身份運行的，負責ora.crsd、ora.ctssd、ora.drivers.acfs和diskmon的啟動、關閉和檢查，這些進程也都是以root身份運行的。

1．ora.crsd

這個 daemon 負責啟動管理應用資源的 Agent。Oracle 10.2 Clusterware 的 CRSD 是通過RACG框架來管理資源，而Oracle 11.2 Grid的CRSD是通過Agent來管理資源的。

2．ora.ctssd

這個 daemon負責處理時間同步。Oracle數據庫用SCN來跟蹤操作發生的先后順序，數據的完整性也靠SCN來保證，SCN是根據時間戳實現的。因此集群里所有節點的時間必須同步。

Grid 11.2之前依靠的是操作系統自帶的時間服務器NTP，不過NTP并沒考慮RAC的要求，NTP調整時間的方式會引起節點的重啟，因此需要對NTP做特別的設置，于是Oracle引入了自己的同步機制。

CTSS既可以取代NTP也可以和NTP合作使用。具體的細節可以參考2.3.3節。這個進程的日志文件為$GRID_HOME/log/hostname/ctssd/ctssd.log。

3．ora.diskmon

Diskmon daemon用以監控Exadata中的Cell Server，只有在Exadata環境中才有用。但是在Grid版本11.2.0.1和11.2.0.2中有個bug，即便是非Exadata環境也會默認啟動該守護進程。到了版本11.2.0.3，改進了這一細節，非Exadata環境無法啟動Diskmon了。

4．ora.drivers.acfs

這個進程負責保證ACFS驅動的加載，確保ACFS可用。這個進程的日志會寫到系統日志及控制臺中。

4.3.4 ohasd 的 cssdagent 和 cssdmonitor

之前說到Clusterware中有兩個關鍵進程oprocd和oclsmon。在Grid 11.2中，這兩個進程沒有了，取而代之的是這兩個 Agent，所以它們的作用和原來那兩個進程是一樣的。cssdagent負責cssd進程的啟動、關閉和檢查，而cssdmonitor監控cssdagent。

這兩個進程和ocssd進程都運行在實時（real time）模式下，因為這可以保證有效的調度，任何一點調度上的延遲都可能會被看做是進程的掛起，會導致節點被隔離。

這幾個進程的日志分別在：

$GRID_HOME/log/hostname/agent/ohasd/oracssdagent_root/agent/ohasd/oracssdagent.root.log、

$GRID_HOME/log/hostname/agent/ohasd/oracssdmonitor_root/oracssdmonitor_root.log

注意：從Clusterware 10.2.0.4開始，Linux RAC就不再需要配置的hangcheck-timer模塊了。

4.3.5 CSSD

在Clusterware時期，CSS就是保證集群穩定的基石。

它主要管理節點成員信息并分發配置，所有成員節點上的CSSD進程間會產生網絡心跳，CSSD 的網絡心跳以及 Voting Disk 的磁盤心跳共同用來監視集群的健康狀況和節點的成員身份，當有節點加入或者離開集群時，也是由 CSSD 進行投票并通知注冊的進程組發起集群重構。

到了Grid，CSSD仍然是整個集群的基礎，而且其工作機制和作用方式也沒變，如果CSSD不能正常啟動，這個節點還是不能加入到集群。

CSSD的日志文件為$GRID_HOME/log/hostname/cssd/ocssd.log。

4.3.6 CRSD

Clusterware中的CRSD是負責應用資源的可用性，比如數據庫。負責啟動、關閉、重新分配（Relocate）這些資源；還負責維護 OCR 中資源記錄的完整性。另外，CRSD 還負責 OCR的備份。

這些功能在Grid中仍然保留，除此之外，CRSD還負責啟動兩個Agent，分別是ORAAGENT和ORAROOTAGENT。CRSD的日志文件為$GRID_HOME/log/hostname/crsd.log。

1．CRSD的oraagent

如果Grid和RDBMS是用兩個用戶安裝的，基本都是一個grid、一個oracle。這樣就會啟動兩個oraagent，一個以grid用戶身份運行，另一個以oracle用戶身份運行。其中grid的這個oraagent負責diskgroup、node listener、scan listener、ons、eons，而oracle這個oraagent負責數據庫、實例和服務。

Grid用戶的日志文件為$GRID_HOME/log/hostname/agent/crsd/oraagent_grid/oraagent_grid.log。

2．CRSD的orarootagent

CRSD啟動的這個以root身份運行的Agent負責管理GNS、VIP、node vip、scan vip等網絡資源。它的日志文件為$GRID_HOME/log/<hostname>/agent/crsd/orarootagent_root.log。

3．CRSD的scriptagent

如果使用Grid監管第三方應用程序，比如Tomcat，也必須通過Agent框架，這些資源就是通過這個 Agent 進行管理的。它的日志文件為$GRID_HOME/log/hostname/crsd/scriptagent_grid/scriptagent_grid.log。

這就是Grid框架中涉及的一些重要服務和進程，下面再來看整個Grid棧的啟動順序，并這些進程在其中的位置標出來。

4.4 Grid的進程和啟動順序

在用 Clusterware 時，Clusterware 是隨著操作系統的啟動而自動啟動，具體說就是由操作系統的INIT啟動了CRSD、CSSD、EVMD三個進程。

以后的運行過程中，如果EVMD、CRSD進程異常掛了，操作系統會自動重啟這兩個進程，如果CSSD掛了，整個操作系統會自動重啟。

這些是通過/etc/inittab中的這3條內容體現的，這些內容也是在Clusterware部署過程中自動添加的：

h1:3:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1 </dev/null

h2:3:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1 </dev/null

h3:3:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1 </dev/null

到了Grid后就變化了，Grid部署過程會自動在/etc/inittab文件中添加一條內容，具體如下：

h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null

也就是說，Grid棧的啟動仍然是由操作系統觸發的。在操作系統的啟動過程中INIT會啟動init.ohasd腳本，后者會啟動OHASD進程（Oracle High Availability Service Daemon），從這個時刻開始，整個Grid棧的啟動正式拉開了序幕。

雖然Grid棧要比Clusterware復雜得多，但是Grid棧的層次結構很清晰，它的啟動進程也是層次分明，可以分成4個級別或者4個階段。下面我們依次解釋。

1．級別1：OHASD的活動

這個階段是 OHASD 的舞臺，OHASD 要啟動 4 個 Agent ，分別是 ORAAGENT、ORAROOTAGENT、CSSDAGENT和CSSDMONITOR。

CSSDAGENT：這個Agent以root身份運行，負責啟動CSSD，對應的進程名字是cssdagent；

ORAROOTAGENT：這個Agent以root身份運行，負責管理所有屬于root用戶的OHAS資源，對應的進程名字是orarootagent.bin；

ORAAGENT：這個Agent以grid身份運行，負責管理所有屬于grid用戶的ohasd資源，對應的進程名字是oraagent.bin；

CSSDMONITOR：這個進程以root身份運行，和CSSDAGENT一起負責監控CSSD以及節點的健康狀況，對應的進程名字是cssdmonitor。

注意：記住這些進程是由ohasd.bin啟動的，而不是CRS或者CSS啟動的，因為這個時候還沒有這兩項呢，這也是不同于Clusterware的。

階段1結束時，舞臺上多出了4個“小生”，于是舞臺就交給他們并進入到了第二個階段。在這個階段，每個“小生”又都有自己的任務。

2．級別2：ROOTAGENT的活動

由OHASD啟動的orarootagent要啟動以下幾個進程。

CRSD：這個進程是我們的老朋友了，它以root身份運行，對應的進程名字是crsd.bin。

CTSSD：Cluster Time Synchronization Services Daemon，只是Oracle Grid自己的時間同步服務，也是以root身份運行，對應的進程名字是octssd.bin。

Diskmon：在非Exadata機器上是無效進程，Grid 11.2.0.3 之后就不再有了，對應的進程名字是diskmon.bin。

ACFS：這是ASM集群文件系統的驅動，以root身份加載。

3．級別2：ORAAGENT的活動

由OHASD啟動的ORAAGENT進程負責啟動下面這些進程和服務，并且這些服務是以grid身份運行的。

ASM：ASM實例，用于掛載磁盤組。

EVMD：對應的進程名字是evmd.bin。

MDNSD：對應的進程名字是mdnsd.bin，取決于是否使用GNS服務。

GIPCD.bin：對應的進程名字是 gipcd.bin ，用于進程間（ inter-process ）和節點間（inter-node）通信協議。

GPnPD：對應的進程名字是gpnpd.bin。

4．級別2：CSSDAGENT的活動

CSSDAGENT啟動ocssd.bin，這個進程以Grid用戶身份運行。CSSDAGENT不再啟動其他進程。

5．級別3：CRSD的活動

CRSD會啟動兩個或三個Agent，ORAROOTAGENT和ORAAGENT。如果Grid和Database的安裝用戶不是同一個，就會創建兩個ORAAGENT。

再重申一遍，OHASD和CRSD都會創建自己的一組Agent，于是從操作系統上我們可以看到多個同名的agent進程，比如：

[oracle@indexserver1 ～]$ ps -ef|grep oraagent

Grid　6161　1　0 Jul18 ?　　03:34:32 /u01/app/11.2.0.2/grid/bin/oraagent.bin

Grid　6782　1　0 Jul18 ?　　01:00:15 /u01/app/11.2.0.2/grid/bin/oraagent.bin

Oracle　9421　1　0 Oct18 ?　　00:12:07 /u01/app/11.2.0.2/grid/bin/oraagent.bin

[oracle@indexserver1 ～]$ ps -ef|grep orarootagent

root　6198　1　0 Jul18 ?　　10:20:53 /u01/app/11.2.0.2/grid/bin/orarootagent.bin

root　6786　1　0 Jul18 ?　　13:18:42 /u01/app/11.2.0.2/grid/bin/orarootagent.bin

oracle　18750 17134　0 10:11 pts/1　　00:00:00 grep orarootagent

oraagent有三個，orarootagent有兩個。不過這兩組Agent的日志文件所在的位置也不一樣，一組位于$LOG_HOME/agent/crsd，另一組位于$LOG_HOME/agent/ohasd。

ORAROOTAGENT：這個 Agent 負責啟動以 root 身份運行的資源，這些資源也可以叫做CRSD資源。

ORAROOTAGENT：這個Agent會有兩個，分別負責管理以grid、oracle身份運行的CRSD資源。

接下來舞臺就交給這幾個Agent，Grid的啟動也進入第4個階段。看看它們都要干些什么？

6．級別4：ORAROOTAGENT的活動

這個Agent負責啟動下面這些資源。

Network Resource：這個資源是Grid 11.2新出現的，對應著Public Network。

SCAN VIP(s)：SCAN是Grid 11.2新出現的，由SCAN VIP和SCAN Listener配對組成。

Node VIPs：這個VIP和Clusterware中的VIP一樣，是Public NIC上的VIP地址，因此每個節點都需要一個VIP。

SCAN VIP和Node VIP類似，都是浮動地址。不同的是，Node VIP在數量上等于節點的個數，每個節點一個。而SCAN VIP和節點數量沒有關系，和集群規模沒關系，固定就是3個（在實驗環境中可以不用DNS，而是用/etc/hosts來解析SCAN域名，這時SCAN VIP可以只要一個，但僅限于實驗環境，生產環境不可以這么做）。SCAN VIP是在DNS上定義的，它和節點之間初始時沒有任何關系，而NODE VIP是通過/etc/hosts定義的，初始時都是和節點配對定義的，只是在運行過程中會出現浮動。

ACFS Registry：用戶掛載ACFS文件系統，后面的章節中會詳細介紹。

GNS VIP（可選）：GNS的VIP。如果不使用DNS而使用GNS來解析SCAN名字，那么就需要知道Grid中的這個GNS服務本身也是高可用的，也就是它是在集群內浮動的，因此，它對外的訪問渠道IP是VIP，也是虛擬浮動的。

7．級別4：ORAAGENT的活動（Grid用戶）

以Grid身份運行的ORAAGENT會啟動以下這些資源。

ASM資源：ASM實例。

Diskgroup：管理和監視ASM磁盤組。

SCAN Listener：監聽SCAN VIP的監聽器。

Listener：監聽節點VIP的節點監聽器。

ONS：Oracle Notification Service（Oracle事件通知服務）。

eONS：增強版的ONS。

GSD：向后兼容Oracle 9i的服務，如果環境中沒有Oracle 9i數據庫，這個進程不會啟動。

GNS（可選）：Grid Naming Service，代替DNS處理名字解析。

8．級別4：ORAAGENT的活動（Oracle用戶）

這個Agent的任務貌似比較少，但是直接關系到用戶的使用體驗。

DB：管理和監視DB和實例；

Service：管理和監視Service。

上面這些進程除了 ONS 之外，其他的都位于$GRID_HOME/bin 目錄下，而 ONS 位于$GRID_HOME/opmn/bin目錄下，eONS是一個Java程序，因此也不是從$GRID_HOME/bin目錄下啟動，不過對應的JAR文件是在$GRID_HOME/bin目錄下。

4.5 配置文件

在Oracle Clusterware和Oracle Grid 11.1中，集群的配置信息保存在OCR中，這個文件中同時記錄著集群的信息以及由集群維護的資源信息。而Voting File記錄的是節點成員身份信息。

到了Oracle Grid 11.2后，由于集群架構被拆分成了兩層，OCR配置文件同樣被做了相應的拆分，原來的一個OCR現在拆成了OLR和OCR，另外，還有一個GPnP也是屬于配置文件。這樣拆分的目的就是集群的歸集群、資源歸資源，歸屬清楚。用于集群的是GPnP和OLR（Oracle Local Registry），用于資源的是OCR。

于是，集群的構成信息現在就來自于3個文件：VotingFile、OLR和GPnP，這3部分共同構成了集群的信息。而OCR是給CRSD管理Cluster中的資源的。盡管OCR中也會記錄一些本地資源的信息，但對于本地節點加入到集群這樣的處理是不需要 OCR 的，因為這些信息是來自于OLR和GPnP的。比如，集群的互聯信息是在GPnP中記錄的。

先來看第一個配置文件GPnP。

4.5.1 GPnP（Grid Plug and Play）

GPnP Profile是一個XML文件，保存在每個節點的本地，這個文件所記錄的信息是這個節點要加入到集群中所需要的最基礎的信息。這個文件也需要節點間的同步，Grid中專門設計了GPnPD（Grid Plug and Play Daemon）來負責這個文件的同步工作。

下面是這個文件的內容，可以使用gpnptool得到這些內容：

<?xml version="1.0" encoding="UTF-8"?>

<gpnp:GPnP-Profile Version="1.0" xmlns="http://www.grid-pnp.org/2005/11/gpnp-profile" xmlns:gpnp="http://www.grid-pnp.org/2005/11/gpnp-profile" xmlns:orcl="http://www.oracle.com/gpnp/2005/11/gpnp-profile" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi: schemaLocation="http://www.grid-pnp.org/2005/11/gpnp-profile gpnp-profile.xsd" Profile- Sequence="4" ClusterUId="0829b9ed4ba4dff6ffb88b20d6be239f" ClusterName="indexgrid" PALoca-tion="">

<gpnp:Network-Profile>

<gpnp:HostNetwork id="gen" HostName="*">

<gpnp:Network id="net1" IP="192.168.1.0" Adapter="eth0" Use="public"/>

<gpnp:Network id="net2" IP="10.0.0.0" Adapter="eth1" Use="cluster_interconnect"/>

</gpnp:HostNetwork>

</gpnp:Network-Profile>

<orcl:CSS-Profile id="css" DiscoveryString="+asm" LeaseDuration="400"/>

<orcl:ASM-Profile id="asm" DiscoveryString="ORCL:*" SPFile="+DATA/indexgrid/asmparame-terfile/registry.253.787835657"/>

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

<ds:Reference URI="">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">

<InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="gpnp orcl xsi"/>

</ds:Transform></ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>F7XCODDT+nhYjFsT/lmO3ROPj8o=</ds:DigestValue>

</ds:Reference></ds:SignedInfo>

<ds:SignatureValue>gnPGH5rLhYwl1pdw4Fq2wrTwiZD3tM7JfUTr9QLeGCCXwgFLmThpgI+24C3I8p3sY0 rn6KMGEaFy92tNwKZlqQJSzSZuSRInjBhlPa4rqq49xqsjr1QIuwTLvpRltxr9JoxNu5Ny79uGyOjpcRFxNsLiCaWv ZEDsB8KwYp6W1S8=

</ds:SignatureValue>

</ds:Signature>

</gpnp:GPnP-Profile>

我們能從這個文件中看到集群的一些重要信息，比如集群的名字ClusterName，gpnp:Network記錄著集群所使用的共有網絡和私有網絡。

ASM Discovery String也出現在這里。集群啟動時CSS會按照這個信息掃描這些ASM磁盤或者磁盤頭部的元信息。Clusterware時，集群和ASM是沒有任何關系的，這個數據是被記錄在ASM的參數文件中的。而Grid中Clusterware是依賴于ASM的，比如Clusterware的Voting File和OCR都保存在ASM磁盤上，二者的關系就像是先有蛋還是先有雞那么糾結，于是集群就通過把ASM Diskcover string記錄到這個文件中來打破這個怪圈。

ASM實例的SPFILE的位置也是記錄在GPnP的，這又是個先有蛋還是先有雞的問題，既然ASM SPFILE放在ASM磁盤中，按理說應該是ASM實例啟動后才能訪問ASM文件，但是ASM實例啟動又必須要依賴SPFILE。解決辦法就是，ASM磁盤頭的元數據中有個標志說明了SPFILE 是否位于這個 ASM 磁盤中以及位于哪一個 AU，于是可以跳過 ASM 實例得到 ASM SPFILE。因此，既保證了ASM實例不再有本地SPFILE，同時也保證了ASM實例在啟動時能夠找到它的SPFILE。

1．關聯命令

Grid 中提供了 gpnptool命令，供用戶訪問 GPnP，比如可以這樣得到上面所展示的 GPnP內容：

[grid@indexserver3 ～]$ gpnptool get

2．關聯文件

與GPnP 關聯的文件有兩個，一個是GPnP Profile，另一個是GPnPD 的trace 文件，這兩個文件分別位于不同的位置。

GPnP Profile：$GRID_HOME/gpnp/profiles/peer/profile.xml。

GPnPD trace：$GRID_HOME/log/<hostname>/gpnpd/gpnpd.log。

4.5.2 OLR（Oracle Local Registry）

OLR文件中記錄的是本地節點的元數據，可以把 OLR 看作是 OCR 的本地替身，這也是Grid引入的新特性。OLR中記錄的是OHASD啟動所必需的信息，如GPnP的wallet。它和GPnP文件一起提供了這個節點要加入到集群中所需要的信息，OCR中記錄的是CRSD需要的信息。因此，OHASD棧的啟動只需要OLR、GPnP profile就可以，并不需要OCR的內容。它的內容格式和OCR一樣，也是key、value格式。如果把OLR和OCR內容進行對比，就會發現OLR中記錄的key更少。OLR是由OHASD管理的。

OLR本身就是對OCR的提取，因此內容格式和OCR一樣，只是內容更少，它也不需要在集群中共享。所有用于OCR的命令也可以用于OLR，只是需要給這些命令加上-local參數。比如：

ocrdump –local

每個節點只需要一個OLR文件，文件的位置如下。

1．關聯文件

在Clusterware中，OCR放在什么位置是通過一個叫做ocr.loc的文件記錄的，這個文件一般放在/etc/oracle/ocr.loc，文件的內容是這樣：

ocrconfig_loc=/dev/rdsk/emcpower1a

ocrmirrorconfig_loc=/dev/rdsk/emcpower5a

local_only=FALSE

這里記錄了OCR的位置以及OCR鏡像的位置。OLR也是延續了這種使用方法，OLR使用/etc/oracle/olr.loc這個文件來記錄OLR文件的位置的，例如：

[root]# cat /etc/oracle/olr.loc

olrconfig_loc=/u01/app/11.2.0/grid/cdata/racassur-ipfix01.olr

crs_home=/u01/app/11.2.0/grid

2．關聯命令

因為OLR就是從OCR中提取出來的，所以二者的內容格式也完全一樣。同時，二者使用的命令也是一套，原來用于OCR的ocr***系列命令同樣也適用于OLR，只是需要加上一個額外的參數local就行。例如，想檢查OLR內容，可以這樣做，用root身份運行：

[root@indexserver1 ～]# /u01/app/11.2.0.2/grid/bin/ocrcheck -local

Status of Oracle Local Registry is as follows :

Version　　　　　:　　3

Total space (kbytes)　:　262120

Used space (kbytes)　　:　　2576

Available space (kbytes) :　259544

ID　　　　　　: 1739919467

Device/File Name　　: /u01/app/11.2.0.2/grid/cdata/indexserver1.olr

Device/File integrity check succeeded

Local registry integrity check succeeded

Logical corruption check succeeded

再比如，OLR本身是有自動備份機制的，初次安裝、每次升級OLR會自動備份，我們也可以手工備份。這個命令是這樣的：

[root]# / /grid/bin/ocrconfig -local –manualbackup

4.5.3 OCR（Oracle Cluster Registry）

Oracle 11.2把原來的CRS拆成了兩部分，OHASD負責管理低級的進程，而CRSD管理高級的資源，CRS的配置信息也被拆分成了兩部分，OHASD管理的是OLR，而CRSD管理的是OCR。原來CRS是通過RACG框架來管理資源的可用性的；Oracle Grid 11.2使用基于Agent的框架來管理可用性。

OCR中保存的是由集群管理的資源的元數據和Wallet。所有CRSD以及Agent所管理的資源信息是在OCR中記錄的，這一點和Clusterware是一樣的。

說明：盡管 OCR 中也會記錄一些本地資源的信息，但是對于節點加入到集群這樣的過程并不需要OCR，因為這些信息來自于OLR和GPnP。

Oracle Clusterware的OCR要放在集群文件系統或者裸設備，不支持ASM。

Grid 11.2不再支持裸設備，OCR是作為普通的ASM文件保存在ASM中。但是CRSD不能直接讀取ASM磁盤，必須要通過ASM實例才行，因此也就是說必須先把ASM實例啟動，然后ASM實例掛載包含OCR的ASM磁盤組，然后CRSD才可能啟動。

如果要想關閉 ASM 實例，必須先關閉連到 ASM 實例的客戶端，因此也就是必須要先關閉CRSD，同樣，就算是不關閉ASM實例而只是想卸載一個磁盤組，如果OCR是在這個磁盤組上的話，也必須先關閉CRSD。否則，就會遇到下面這個錯誤，這個錯誤也是我剛使用Grid時常遇到的，因為當時只安裝了Grid，還沒有安裝數據庫軟件，更談不上數據庫了。所以一度對這個提示很郁悶，搞不清楚到底是誰連接了 ASM 實例。后來才明白，是因為這個原因在作祟。

ORA-15097: cannot SHUTDOWN ASM instance with connected client

1．關聯文件

Grid中記錄OCR所在位置的方式沒變，仍然是通過/etc/oracle/ocr.loc文件來記錄的，下面是一個實例：

[root@indexserver1 ～]# more /etc/oracle/ocr.loc

ocrconfig_loc=+DATA

local_only=FALSE

可見這個文件保存在ASM的DATA磁盤組上。

2．關聯命令

和OLR共用同一組命令，不過不用-local參數。比如，檢查OCR文件的內容：

[root@indexserver1 ～]# /u01/app/11.2.0.2/grid/bin/ocrcheck

Status of Oracle Cluster Registry is as follows :

Version　　　　　:　　3

Total space (kbytes)　:　262120

Used space (kbytes)　　:　　3684

Available space (kbytes) :　258436

ID　　　　　　: 1126146844

Device/File Name　　:　+DATA

Device/File integrity check succeeded

Device/File not configured

Device/File not configured

Device/File not configured

Device/File not configured

Cluster registry integrity check succeeded

Logical corruption check succeeded

3．OCR的自動備份

Clusterware 會自動地備份 OCR 文件，每隔 4 個小時就會進行一次備份，備份文件放在$GRID_HOME/cdata/<cluster_name>目錄下。Clusterware 會自動保留一份周備份、日備份以及最后3次的備份，我們可以這么檢查這幾份備份：

[root@indexserver1 ～]# /u01/app/11.2.0.2/grid/bin/ocrconfig -showbackup

indexserver4　2012/09/18 10:55:03　/u01/app/11.2.0.2/grid/cdata/indexgrid/backup00.ocr

indexserver4　2012/09/18 06:55:02　/u01/app/11.2.0.2/grid/cdata/indexgrid/backup01.ocr

indexserver4　2012/09/18 02:55:01　/u01/app/11.2.0.2/grid/cdata/indexgrid/backup02.ocr

indexserver4　2012/09/17 02:54:55　/u01/app/11.2.0.2/grid/cdata/indexgrid/day.ocr

indexserver4　2012/09/06 02:53:55　/u01/app/11.2.0.2/grid/cdata/indexgrid/week.ocr

需要注意的是，這個備份只在一個節點上進行，所以用這個命令來確認這些備份是在哪個節點上生成的。

4.5.4 Voting File

Voting File記錄集群的節點以及每個節點的狀態，提供集群節點成員身份管理和節點隔離（fencing）功能。

集群運行過程中，每個節點每秒都要給其他節點發送一個網絡心跳、每秒都要往每個Voting File更新自己的狀態，這些動作用來聲明“我還活著”。同時也會讀取其他節點的信息，知道其他節點的狀況。通過節點的心跳就可以掌握集群的狀態。如果某個節點沒有在一定時間內（CSS有個參數Miscount定義的就是這個時間）發出自己的心跳（包括網絡和磁盤），就認為節點的心跳信息丟失了，那么這個節點就出問題了，或者說這個節點已經失去控制了。這個節點不一定宕機了，有可能還在運行著，上面的數據庫實例、LGWR、DBWR等還在不斷地寫數據。失去了控制就意味著數據破壞，因此集群需要把這個節點踢出集群，避免腦裂和數據破壞。

這時會由某個節點觸發一次重構過程，所謂重構其實就是把節點踢出集群以及之后的掃尾工作，比如處理該實例未提交的事務。

這些節點會通過 Voting File 進行投票（其實就是說有哪些節點能與它通信），根據所有節點的投票，Clusterware就能判斷出健康的集群成員集合，這個新的成員集合組成新的集群。

這只是集群層面的重構，上層的 RAC 數據庫也會被觸發一次數據庫層面的重構。在數據庫開始重構時，會有一段短暫的靜默期，這期間要進行數據恢復，數據庫會暫停對外服務，不接受新的連接請求。因此，RAC并不是完全的24×7。

我們現在所說的是一個非常概括、籠統的過程，其實會有很多進程參與到這個過程中。對于大型的集群來說，最后得到的集群是節點數量最多的集合。

在Grid 11.2中，Oracle允許把Voting File放在集群文件系統中或者裸設備上，不過從Oracle 11.2 開始不再支持裸設備，Voting File 只能放在 ASM 磁盤組或者集群文件系統中。如果是升級方式到Grid 11.2的，Voting File和OCR文件還是能放在裸設備或者塊設備上。

不管是哪一種配置，都需要保持Voting File的數量是奇數個。如果一個集群只有兩個節點，當內部互聯失敗時，可以確保總會有一個節點獲得多數Voting File。如果集群節點數量超過兩個，集群會使用一種更為復雜的算法確定到底哪個節點最終獲得集群的控制權。

不同選型意味著冗余策略會有所差異。如果使用集群文件系統保存Voting File，我們可以配置5個拷貝。這些拷貝應該放在不同的單獨磁盤上，以避免單點故障。如果使用ASM存放Voting File，我們是不能直接控制實際創建的文件數量，ASM會根據所配置的Failure Group的數量來進行鏡像，具體規則如下。

External Redundancy：只會使用一個Voting File。

Normal Redundancy：會有3個拷貝，但要求磁盤組至少要配置3個Failure Group。

High Redundancy：會有5份拷貝，但要求磁盤組至少要配置5個Failure Group。

在配置Voting File時，一定要保證奇數數量，也就是讓節點之間有交叉。這樣，可以容忍節點臨時失去對一個Voting File的訪問。假設有兩個Voting File，兩個節點。節點A丟失了對于Voting 1的訪問，這時，如果節點B丟失了對于Voting 2的訪問，也就是節點A只能訪問Voting 2，而節點B只能訪問Voting 1，這時，兩個節點就無法獲得彼此的信息了，集群就不穩定了。使用3個文件后，就算每個節點都丟失了對一個Voting File的訪問，但是只要還剩兩個，總是會有一個交叉的，因此集群還是不用重構的，如果丟失了對兩個Voting的訪問，就會觸發重構了。

盡管Voting File是保存在ASM磁盤組中，但實際上Voting File是保存在其中的一個磁盤之上的，而不是像普通的ASM文件那樣可能跨越多個磁盤。CSSD是可以直接訪問這個ASM磁盤的，這也是為什么CSS可以在ASM之前被啟動了。

Voting File的命令在Grid中沒有變化，和Clusterware是一樣的，比如查看Voting File的位置：

[root@indexserver1 ～]# /u01/app/11.2.0.2/grid/bin/crsctl query css votedisk

##　STATE　File Universal Id　　　File Name Disk group

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

1.ONLINE 187c6c1cf3d14f57bfa4d5e56133e666 (ORCL:WXXRDATA1) [DATA]

Located 1 voting file(s).

這個輸出顯示，有一個Voting File在ASM磁盤組DATA的唯一一個磁盤上。

4.5.5 OCR、ASM SPfile、Voting file、CRS 和 ASM 的關系總結

最后這一節，我們再把這幾個元素之間的關系梳理一下，我曾一度被這些關系搞糊涂。

回顧一下，OCR、Voting File、ASM SPFILE都在ASM磁盤組中。

（1）CSSD負責維護集群的節點成員身份，啟動它需要有Voting File，Voting File是保存在ASM磁盤組的，因此CSSD需要依賴于ASM。

（2）CRSD負責維護集群的上層資源，它需要用到OCR，OCR也是保存在ASM磁盤組上的，因此CRSD需要依賴于ASM。

（3）ASM 本身就是一個沒有數據文件的數據庫而已，啟動 ASM 實例需要它的參數文件SPFILE，以前 SPFILE 是保存在節點本地的$ORACLE_HOME 里的，Grid 11.2 中它是保存在ASM 磁盤組中的。既然它是個普通的 ASM 文件，一定要啟動 ASM 實例，我們需要能訪問SPFILE，因此要啟動ASM實例，必須先有ASM實例，然后將ASM實例作為自己的一個客戶端訪問自己。

如果照這些問題的思路下來，Oracle Grid 11.2中ASM應該是一個最底層的支撐元素，它應該位于整個Grid軟件棧最底下一層才對，但我們知道，ASM只是CRS所維護的一個資源而已。那這些糾結的問題又是如何解決的呢？這一節就把這些問題做統一的解答。

在Oracle Grid 11.2之前，這些元素之間的關系比較簡單，Clusterware需要OCR和Voting File才能運行，OCR和Voting File又是放在裸設備上的，所以Clusterware完全不需要ASM。ASM實例的啟動需要ASM SPFILE，ASM SPFILE保存在本地的$ORACLE_HOME中的，所以ASM實例的啟動也和普通數據庫實例一樣。

到了Grid 11.2后，這種簡單的關系被攪亂了，ASM和Clusterware被合成一體，于是二者之間相互依賴又相互作用。

Oracle Grid 11.2中，OCR是按照一個普通的ASM文件形式放在ASM磁盤組中的，這一點和ASM SPFILE一樣，但是又與Voting Fisk不同。OCR和ASM SPFILE這兩個文件都是普通的 ASM 文件。比如，使用 asmcmd 命令可以很容易地看到 ASM 磁盤組中的 OCR、ASM SPFILE，但看不到Voting File。

[grid@indexserver1 ～]$ export ORACLE_SID=+ASM4

[grid@indexserver1 ～]$ asmcmd

ASMCMD> ls

DATA/

ASMCMD> cd DATA

ASMCMD> ls

indexgrid/

ASMCMD> cd indexgrid

ASMCMD> ls

ASMPARAMETERFILE/

OCRFILE/

ASMCMD> cd OCRFILE

ASMCMD> ls

REGISTRY.255.787835657　-------------OCR文件

ASMCMD> cd ../ASMPARAMETERFILE

ASMCMD> ls

REGISTRY.253.787835657　-------------ASM SPfile

因為OCR是一個普通的ASM文件，因此CRS啟動需要先啟動ASM實例、掛載磁盤組，然后OCRSD才能以ASM客戶端的身份連接到ASM實例，透過ASM實例訪問OCR文件，然后CRS才得以啟動。這就是CRS和ASM的依賴關系。因此，在Oracle Grid 11.2中，如果想關閉ASM實例，我們必須同時關閉CRS，正確的關閉方法就是crsctl stop crs。這一點已經多次講過了。

好了，OCR是當作一個普通的ASM文件使用的，CRS和ASM的依賴關系也清楚了。

SPFILE和Voting File這兩個問題的解決方法是一樣的。

Grid 11.2的ASM磁盤盤頭中添加了新的元數據，包括標記（marker）、Voting File在磁盤上的開始位置（staring Allocation Unit）（kfdhdb.vfstart）以及Voting File在磁盤上的結束位置（ending AU）（kfdhdb.vfend）。標記是表明這個磁盤上是否有Voting File，后兩個位置數據告訴CSS 到哪里找 Voting File。這樣一來只需要掃描這些元數據，即使不啟動 ASM 實例，也是可以獲得Voting File位置信息的，也就能夠找到它，一旦找到了Voting File，CSS就可以加入到集群中。這些數據結構可以用kfed 工具來查看。對于ASM SPFILE 的處理也是同樣。回顧一下Grid的GPnP參數文件，這個文件中記錄了Voting File、ASM SPFILE的Diskcover String，綜合這些信息，Grid就可以找到這兩個文件了。

<orcl:CSS-Profile id="css" DiscoveryString="+asm" LeaseDuration="400"/>

<orcl:ASM-Profile id="asm" DiscoveryString="ORCL:*" SPFile="+DATA/indexgrid/asmparameterfile/registry.253.787835657"/>

也就是說，對這兩個文件的訪問并不是透過 ASM 實例完成的，而是借助 ASM 驅動直接從磁盤上讀取的。

4.6 小結

在這一章中，我們對Oracle Grid做了深入的剖析，討論了Grid的幾大組件：文件、進程、啟動順序、相互關系。

這一部分的內容比較枯燥，我試圖把它們講解得生動有趣易于理解，因為搞清楚每一個細節，對技能的進步和提高是最有效的，而且這種“從小處著手”的學習方式也能培養我們“從大處著眼”的意識和態度。