之所以要分享這個主題，是因為當我第一次遇見 CRS 無法正常啟動的故障時，那種無從下手的無力感，找不到頭緒的慌亂感，我至今記憶猶新。我想很多初學者也和那時的我一樣，面對 CRS 的問題可能會沒有什麼頭緒，其實任何故障的分析都是類似的，如果你能知道它內部的執行原理與機制，相信故障分析對你也會猶如翻掌般輕而易舉。

今天我們就通過相關的日誌檔案來分析一下 CRS 的啟動過程，希望通過這種方法讓大家瞭解 CRS 的啟動過程，以便將來能夠對初學者分析 CRS 的問題時有所幫助。”

首先我們得明確一個概念，CRS 是什麼？

在這裡解釋一下，這裡所說的 CRS 並不是指 CRSD 程序，而是為了 RAC 高可用資料庫所提供一套叢集軟體 The Oracle Clusterware。

那麼，下面我們正式開始今天的主題，首先我們來看一下下面的“RAC 元件啟動關係圖”。由於 oracle 各個版本之間存在差異，本次所使用的版本為 11g R2。之後會通過相關 trace 與 log 檔案的內容讓大家更加清晰的看到這些元件的啟動過程以及他們都做了什麼。

通過上面的 RAC 元件啟動關係圖，我們可以大致的瞭解到 CRS 的各個元件啟動的關係。

整個啟動流程看起來還是很複雜的，同時層次也很鮮明。當然，這裡面最重要的主要是 OHASD 到 CSSDAGENT，OHASD 到 ORAROOTAGENT 再到 CRSD，最後 CRSD 啟動所管理的應用程式（或者叫做應用程式資源）啟動這幾大步。

僅僅是看這幅圖，對於初學者來說很難記得住，沒有關係，圖可以保留下來慢慢看，我們換個思路，從這些程序的相關日誌檔案內容，來了解上圖所表達的含義。

當然，想檢視 RAC 相關日誌，首先得找到他們，下面列出了 RAC 的 CRS 相關日誌檔案的位置：

Clusterware daemon logs are all under  <GRID_HOME>/log/<nodename>.  Structure under  <GRID_HOME>/log/<nodename>:

 alert<NODENAME>.log - look here first for most clusterware  issues

 ./admin:
 ./agent:
 ./agent/crsd:
 ./agent/crsd/oraagent_oracle:
 ./agent/crsd/ora_oc4j_type_oracle:
 ./agent/crsd/orarootagent_root:
 ./agent/ohasd:
 ./agent/ohasd/oraagent_oracle:
 ./agent/ohasd/oracssdagent_root:
 ./agent/ohasd/oracssdmonitor_root:
 ./agent/ohasd/orarootagent_root:
 ./client:
 ./crsd:
 ./cssd:
 ./ctssd:
 ./diskmon:
 ./evmd:
 ./gipcd:
 ./gnsd:
 ./gpnpd:
 ./mdnsd:
 ./ohasd:
 ./racg:
 ./racg/racgeut:
 ./racg/racgevtf:
 ./racg/racgmain:
 ./srvm:

在知道了日誌檔案的位置之後，我們將沿著啟動日誌來觀察整個 CRS 啟動的過程。

這裡啟動環境為2節點 rac，版本是11.2.0.4，作業系統是 RedHat 6，同時第二節點的 CRS軟體是關閉的，這樣使得分析啟動過程會簡單明瞭些。

在 CRS 啟動時，第一個被記錄的就是告警日誌，那麼我們就從告警日誌開始看起，RAC 的告警日誌是一個被放在 <GRID_HOME>/log/<nodename> 目錄下的，名為 alert<NODENAME>.log 的文字檔案：

從告警中的紅字部分可以看出，第一步需要完成 OLR 服務與 OHAS 服務的啟動。簡單介紹下這兩個服務的作用：

OLR 是儲存在本地的叢集登錄檔，主要作用就是為 ohasd 守護程序提供叢集的配置資訊和初始化資源的定義資訊。當叢集啟動 ohasd 時會從 /etc/oracle/olr.loc 檔案中讀取 OLR 的位置。OLR 預設為 $GRID_HOME/cdata/<node_name>.olr

關於 OLR 的內容可以通過 ocrdump -localfilename 匯出到檔案中檢視

OHASD 從 11g R2 版本開始就是叢集啟動的唯一始點。負責管理叢集所有的守護程序對應的資源。

在看守護程序日誌前先簡單介紹下 CRS 中程序的日誌記錄大致格式：

<時間>:[元件][<執行緒編號或者id>]<執行緒名稱>:<訊息內容>

那麼我們來看一下這段時間內 OHAS 服務的日誌，這個日誌被放在<GRID_HOME>/log/<nodename>/ohasd 目錄下，名為 ohasd.log。

通過 OHASD 的日誌中紅色的資訊可以看到，第一步是初始化 OLR 檔案，然後檢查 OLR 中的資訊。最後紅色部分表示 RD(Resource Discovery 資源發現服務)已經啟動了，代表 ohasd 正式啟動了。

接著檢視 ohasd 日誌資訊：

開始啟動 cssdagent、orarootagent、oraagent、cssdmonitor 守護程序，以及初始化一些資源（crf、diskmon、ctss、cluster_interconnect.haip、crsd、mdns、gpnp、gipc、evm、asm、css、cssdmonitor 等）的資訊。

以上資訊為傳送需要啟動的資源給對應的程序，接下來檢視對應的程序日誌（日誌位置參考最開始），檢視這4(cssdagent、orarootagent、oraagent、cssdmonitor)個程序分別負責什麼資源：

我們將日誌啟動的程序從日誌中提取出來檢視：

我們再次回顧一下最開始的那張《RAC 元件啟動關係圖》：

現在想想，整個啟動過程通過日誌內容是不是已經完全對應上了？

這裡我們再簡單介紹下這4個守護程序 (cssdagent、orarootagent、oraagent、cssdmonitor) 的作用：

• Cssdagent: 負責啟動以及監控 ocssd.bin 守護程序。

• Orarootagent: 這個代理程序以 root 使用者啟動，負責管理使用者為 root 的資源。

• Oraagent: 這個程序會以 oracle 或者 grid 使用者啟動(日誌檔名末尾會以_<username>.log 結尾)，負責管理使用者為 oracle 或 grid 的資源。

• Cssdmonitor: 只負責監控 ocssd.bin 守護程序。

接下來的流程中就是由 CRSD 來啟動所有的應用程式（或者說是應用程式對應的資源）了。但是這裡我們先不著急去看啟動對應的資源的資訊，我們重新去看一下這個時候的 CRS 告警日誌資訊所記錄的內容：

從告警日誌中可以看出來，GPNP 啟動後才會有 CSSD 啟動的資訊。CSSD 的啟動至少必須是在 GPNP 啟動完成後才能啟動的。這裡我們觀察一下 OCSSD 的日誌：

從日誌中可以看出叢集版本為11.2.0.4，同時會檢查 GIPC 的狀態，目前檢查結果為 down。

這裡會回答大家的一個疑問，就是怎麼去看這些程序與執行緒的功能。準確的說是怎麼去猜。

目前我並沒有找到一本官方的去說明 CRS 中各個執行緒、元件具體功能的書籍。至少我目前沒有找到，如果誰有的話請發給我一份，謝謝。

這裡我會將我猜的方法告訴大家。

一般情況下，元件名稱為4位的，基本只看前兩位英文或者四位英文去猜測。比如 [AGFW]這個元件，具體是什麼含義呢？我們看前兩位英文為 AG，那麼 CRS 中有什麼單詞是 AG 開頭的呢？就是 AGENT。那麼我們在觀察一下這個元件出現時的日誌，都是與 AGENT 代理程序有關，至少也是與 AGENT 的功能職責有關。前面說過，AGENT 負責管理對應使用者的資源，從之前的日誌中可以看到基本上是在啟動資源。我們沒有辦法明確的知曉 FW 的具體含義（我個人猜測為 FILE WORKSET，不一定對），但是我們至少知道這個元件與 AGENT 有關。

那麼藉助這個思想，我們來分析一下執行緒的具體含義，比如 clssscmain 執行緒。同樣，前兩位是 cl，可以假設為 cluster 的前兩位英文，那麼 CLSS 就等同於 CSS，那麼 clssscmain 這個執行緒就被分解為了 css，scmain 兩部分，而 main 是我們所認識的完整的單詞，現在拿掉。就分解為 sc，main 兩個部分。而 sc 出現在 cssd 的啟動階段，是不是可以理解為 start check，然後組合起來就是 css start check main，css 啟動檢查主執行緒。在去對比一下這個執行緒後面所跟著的內容，你會發現好像就是這麼回事。

藉助這樣子的思想，我們再分析接下來日誌中出現的執行緒的含義：

我們試著猜測下執行緒 clssnmReadDiscoveryProfile 與 clssnmvDDiscThread 的作用。

• clssnmReadDiscoveryProfile：css node manager Read Discovery Profile

• clssnmvDDiscThread：css node manager vote disk Discovery Thread

在根據後面的內容去確定一下，大概就是這麼回事。

這個時候我們去解讀一下剛才的日誌內容。就是 CSSD 的節點管理功能通過讀取 RD profile 找到 voting file 的 string 引數，然後 CSSD 的節點管理功能 vote disk 發現執行緒去查詢 vote disk。

現在我們已經具備了初步閱讀 CRS 日誌的能力，不至於看見什麼都很慌張了。之所以說是初步閱讀，是因為這個方法並不是萬能的，重要的還是平時的積累。當然還有一些其他的方式可以知道某些執行緒、模組的大概功能的，這裡就留給大家去發現了。我們接著閱讀 CSSD 的日誌：

確認只有一節點狀態為 ALIVE，無需重新配置，CSSD 配置完成，再次觀察告警日誌資訊

在 CSSD 啟動後 CTSS、OCR、EVMD、CRSD 相繼被啟動。

這裡對 CTSS、EVMD 以及 CRSD 程序簡單介紹下功能：

• CTSS：負責同步叢集節點時間的元件。有觀察者與活動兩種模式

• OCR：叢集中所有資源的資訊

• EVMD：負責產生並記錄叢集時間，並在節點間傳遞發生的事件

• CRSD：管理叢集中的應用程式（或者說是應用程式對應的資源），以便實現叢集資源的高可用性。同時也管理 OCR

這裡所說的資源大家可以通過命令 crs_stat 檢視：

這些就是由 CRS 所管理的資源。

當 CRSD 守護程序執行起來之後，CRS（The Oracle Clusterware）啟動完成。而之後就開始由 CRSD 負責啟動各種資源，包括資料庫例項（前提是 AUTO_START 引數正確）。

關於 CRS 啟動的順序，官方文件的說明：

Level 1: OHASD Spawns:

• cssdagent     - Agent responsible for spawning CSSD.

• orarootagent     - Agent responsible for managing all root owned ohasd resources.

• oraagent     - Agent responsible for managing all oracle owned ohasd resources.

• cssdmonitor     - Monitors CSSD and node health (along wth the cssdagent).

Level 2: OHASD rootagent spawns:

• CRSD     - Primary daemon responsible for managing cluster resources.

• CTSSD     - Cluster Time Synchronization Services Daemon

• Diskmon

• ACFS     (ASM Cluster File System) Drivers 

Level 2: OHASD oraagent spawns:

• MDNSD     - Used for DNS lookup

• GIPCD     - Used for inter-process and inter-node communication

• GPNPD     - Grid Plug & Play Profile Daemon

• EVMD     - Event Monitor Daemon

• ASM     - Resource for monitoring ASM instances

Level 3: CRSD spawns:

• orarootagent     - Agent responsible for managing all root owned crsd resources.

• oraagent     - Agent responsible for managing all oracle owned crsd resources.

Level 4: CRSD rootagent spawns:

• Network     resource - To monitor the public network

• SCAN     VIP(s) - Single Client Access Name Virtual IPs

• Node     VIPs - One per node

• ACFS     Registery - For mounting ASM Cluster File System

• GNS     VIP (optional) - VIP for GNS

Level 4: CRSD oraagent spawns:

• ASM     Resouce - ASM Instance(s) resource

• Diskgroup     - Used for managing/monitoring ASM diskgroups.  

• DB     Resource - Used for monitoring and managing the DB and instances

• SCAN     Listener - Listener for single client access name, listening on SCAN VIP

• Listener     - Node listener listening on the Node VIP

• Services     - Used for monitoring and managing services

• ONS     - Oracle Notification Service

• eONS     - Enhanced Oracle Notification Service

• GSD     - For 9i backward compatibility

• GNS     (optional) - Grid Naming Service - Performs name resolution

關於 RAC 的 CRS 啟動過程我們就講到這裡，當你瞭解了整個啟動過程後，如果 RAC 在啟動時出錯導致無法啟動，我們就可以根據啟動過程中這些程序的報錯資訊，去分析診斷導致故障的原因，進而快速解決相關的故障。

比如：

• OHASD 無法啟動，我們可以需要去檢視 OLR 檔案是否存在。

• CRSD 一直無法啟動，是不是 CSSD 都不能成功啟動造成。

• CSSD 無法啟動是否 vote disk 出現問題。

這些疑問我們都可以根據瞭解 CRS 的啟動過程去思考，當然了這個啟動過程是最簡單的一種，其他節點都關閉的情況。所以學會去閱讀 CRS 的日誌也是很重要的，這裡也將我自己的思考分享給了大家，希望對大家有幫助。

最後，我們再來思考一個問題：CRSD 與 ASM 誰先啟動呢？

根據官方文件的說法是：

如果 OCR 儲存在 ASM 中,那麼 ora.asm 資源 (ASM 例項) 必須已經啟動而且 OCR 所在的磁碟組必須已經被掛載,否則我們在 crsd.log 會看到以下的類似資訊：

注意：在11.2 的版本中 ASM 會比 crsd.bin 先啟動，並且會把含有 OCR 的磁碟組自動掛載。

在測試中，將 ASM 設定為不自動啟動，然後重啟伺服器，ASM 依然自動啟動，對應的 OCR 磁碟組已經掛載。

今天的分享到此結束，為大家帶來這個主題，也是為了讓大家更清楚地理解 RAC，做到知其然，更能知其所以然。