10月29日，由oracle首席技術支援工程師高斌老師在“dba+東北群”進行了一次關于“rac中的執行個體管理”的線上主題分享。小編特别整理出其中精華内容，供大家學習交流。
嘉賓簡介
《oracle rac核心技術解密》（即将出版）作者
oracle首席技術支援工程師（principal technical support engineer），2007年加入oracle 大連技術支援中心，對oracle資料庫産品有比較深刻的認識。
主要負責oracle rac，exadata的技術支援工作，擅長在壓力環境下處理複雜的資料庫技術問題，多次成功解決國内外客戶重要系統的技術問題。除了日常的技術支援工作以外，還負責mos（https://support.oracle.com）網站上 rac，exadata 文檔的翻譯工作，在oracle 内部定期進行資料庫相關的知識分享，偶爾在oracle 官方部落格（https://blogs.oracle.com/database4cn/）上發表技術文章。
目前，主要緻力于oracle 12c 和 exadata新特性的研究，知識分享和技術支援工作。
演講實錄
什麼是執行個體管理(cgs)
節點管理：這部分功能會負責維護資料庫叢集的節點（或者叫執行個體）清單，確定隻有叢集中的節點能夠通路資料庫，并且在節點加入叢集或者離開叢集時更新節點清單。另外，節點管理還負責和叢集管理軟體進行通信,并向叢集注冊資料庫程序的相關資訊，以便通路資料庫的各種客戶（client）獲得相應的資訊，這部分的功能作者已經在第五章的組管理(gm)部分進行了比較詳細的介紹，這裡就不再過多的描述了。
cgs：這部分功能實際上是oracle rac 的執行個體管理的實作方法，他負責實作執行個體之間的心跳機制；當執行個體離開或者加入叢集時完成資料庫叢集的重新配置；解決資料庫層面出現的腦裂(split-brain)。
是以，nm是實作執行個體管理的基礎，而cgs是具體實作的方式，說他們是一回事也沒什麼問題。
節點清單位圖
節點清單是一個位圖，它記載了每個節點的目前狀态。以一個5節點的叢集為例。首先，五個節點全部正常運作。
叢集對應的節點清單位圖如下圖：
節點清單是一個位圖，它記載了每個節點的目前狀态。以一個5節點的叢集為例。首先，五個節點全部正常運作。叢集對應的節點清單位圖如下圖。稍後，接下來，節點2和4 被關閉。
叢集對應的節點清單位被更新如下圖：
由于叢集的所有節點需要具有一緻的節點位圖資訊，是以這個位圖會以資源的方式存在，也就是nm資源。當某一個節點啟動或者關閉時，叢集中的某一個節點會以獨占（exclusive）的方式持有這個資源，并将最新的節點狀态資訊更新到位圖上去，之後發送最新的位圖資訊給其他的節點，當其他節點收到最新的位圖資訊之後，所有節點就擁有了相同的節點位圖。
心跳機制
rac 資料中包含了3種心跳
網絡心跳（lmon）
磁盤心跳（ckpt+control file）
本地心跳(lms,lmd,lmon,lmhb,lck0)
1、網絡心跳
資料庫層面的網絡心跳是通過lmon程序來實作的，每個執行個體的lmon程序會定期的通過資料庫的私網（cache fusion使用的網絡）和所有遠端執行個體進行通信，确認其他節點（執行個體）的狀态。如果，某一個執行個體一段時間之内（預設300秒）不能夠響應其他節點發送的網絡心跳資訊，那麼資料庫叢集就需要進行重新配置，而使用者能夠看到的最直覺的資訊就是ora-29740 錯誤。
2、磁盤心跳
對于rac資料庫，ckpt程序預設會每3秒鐘向資料庫的控制檔案寫入本地執行個體能夠通路到的其它執行個體資訊，進而完成資料庫執行個體的磁盤心跳。
3、本地心跳
事實上，本地心跳的概念是從11gr1版本開始被引入的。從11g版本開始，本地的lms,lmon 和lmd程序會定期檢查彼此的狀态，如果發現了某一個程序出現了問題（最常見的就是hang（挂起）住），就可以通過重新啟動執行個體的方式來維護資料庫叢集的一緻性。這種行為是通過以下的三個隐含參數來控制的：
_lm_rcvr_hang_check_frequency：這個參數指定了程序之間彼此檢查狀态的時間間隔。該參數預設值為 60秒。
_lm_rcvr_hang_allow_time：這個參數指定了一個程序處于hang狀态的最大逾時時間 。該參數預設值為200秒。
_lm_rcvr_hang_kill：這個參數指定了當一個程序處于hang狀态的時間超過了_lm_rcvr_hang_allow_time之後，是否允許重新啟動資料庫執行個體。該參數預設值為 false
心跳機制
腦裂
資料庫層面的腦裂是指當資料庫叢集節點之間由于網絡問題導緻了彼此不能通路的情況，腦裂在絕大部分情況下出現在雙節點的資料庫叢集丢失網絡心跳的情況下。是以，資料庫層面的腦裂和叢集層面的腦裂是比較類似的，但是在處理方式上卻有所不同。
首先，兩個執行個體之間的私有網絡出現問題。在一段時間之後（預設300秒），兩個執行個體都發現無法和對方進行通信。
然後，每個執行個體都嘗試獲得rr 鎖（就是有些資料提到的要去搶表決盤，當然這裡的表決盤是指控制檔案），獲得了rr鎖的執行個體通路控制檔案中的執行個體狀态，并決定新的叢集執行個體清單。當然，結果一定是獲得了rr鎖的執行個體會存活，另外一個執行個體被驅逐。而最直接的資訊就是在資料庫的alert log當中出現了原因3的ora-29740 錯誤。
接下來發生的過程就和正常的資料庫重新配置過程一樣了。
注意：叢集層面處理腦裂的方式和資料庫層面是不同的。
執行個體恢複
rac系統中的執行個體恢複是指當某一個（或多個）執行個體離開叢集後，重新配置主節點會将離開叢集執行個體對應的redo thread中的重做日志檔案中對資料的改變（redo entries）應用到資料庫。這個過程實際上和單執行個體當中的執行個體恢複過程是很類似的，但是由于rac資料庫存在cache fusion， 也就是說同一個資料塊可能被多個執行個體修改，是以恢複的過程可能和單執行個體有所不同。
階段一：負責執行恢複執行個體的smon程序獲得ir（instance recoverr）鎖,并通知其它執行個體開始進行執行個體恢複。之後進行第一次redo log分析，主要目的是為了建構recover set（恢複集）。
階段二：擷取恢複所需要的cache fusion lock。根據recover set 中包含的資料塊，向其他執行個體申請對應資料塊所需要的鎖和block。
階段三：開始恢複redo中的資料庫改變，根據recover set 中的資訊開始媒體恢複。在完成執行個體恢複後，釋放ir鎖，并通知其它執行個體恢複結束。
執行個體恢複—備份集
q&a精選
【問題1】12c的rac有沒有什麼重大變化？
答：12c rac 資料庫層面變化不是特别大。不過gi層面發生了挺大的變化。
【問題2】重構的時候，日志中有重構耗時，這段時間内（10秒左右）進行執行個體恢複的塊涉及和對象是否無法進行dml操作？
對執行個體恢複隻能由一個執行個體完成。
【問題3】現在linux都是64位了，hugepage不用配置了，這句話說的對嗎？rac 配置huge，一個新裝的生産linux rac需要馬上配置上huge page嗎，系統記憶體多大，sga多大的庫适合配置huge page?
huge page不是必須的，但是如果sga很大的話最好配上。oracle沒有固定的限制，一般情況下我個人的經驗要是sga超過100g就用huge page。
【問題4】對于新手如何學習rac?
新手學習rac，我的建議就是多動手，動手有疑問都看文檔。
【問題5】bwr是什麼？為何包含在了bwr中，就要删除出去？
bwr叫block write record, 在建構恢複集的時候如果碰到了bwr就會把對應的資料塊從恢複集裡面删掉。
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2015-10-30</b>