程昌明
雲和恩墨技術專家
本文整理來自上周四雲和恩墨大講堂程昌明的分享：通過 Oracle 日誌文件了解 CRS 的啟動過程。
「之所以要分享這個主題，是因為當我第一次遇見 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 的作用。
在根據後面的內容去確定一下，大概就是這麼回事。
這個時候我們去解讀一下剛才的日誌內容。就是 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:
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，做到知其然，更能知其所以然。
搜索蓋國強（Eygle）微信號：eeygle，或者掃描下面二維碼，備註：雲和恩墨大講堂，即可入群。每周與千人共享免費技術分享，與講師在線討論。
應用軟體開發：數據建模 | SQL審核和優化 | 中間件服務
電子渠道（網絡銷售）分析系統 | 數據治理