http://www.itpub.net/thread-1106961-1-1.html
1. RAC資源調度概述
集羣操作需要在所有的節點間進行同步來控制對共享資源的訪問，在一個集羣數據庫裏面RAC使用全局資源目錄（Global Resource Directory）來記錄怎樣使用資源的信息，全局緩存服務（Global Cache Service (GCS)）和全局隊列服務（Global Enqueue Service (GES)）管理其中的目錄信息。每個實例在SGA裏維護一部分全局資源目錄。
RAC調度資源既在一個實例級又在一個集羣數據庫級發生。RAC中的實例級資源調度也就是本地資源調度，集羣級調度也就是全局資源調度。
在一個集羣數據庫中本地資源調度進程同一個單實例本地資源調度進程是一樣的，這就意味着行和數據塊級訪問、空間管理、生成SCN、數據字典緩存和庫緩存管理在RAC中是和單實例數據庫一樣的。
1.1. 全局資源目錄的內容
每個實例的全局資源目錄的一部分包含當前共享資源狀態的信息，oracle在實例失敗或集羣重配置是也使用這些信息。
在全局資源目錄中的共享資源信息內容包括以下類型:
• 數據塊標識符, 例如一個數據塊地址
• 當數據塊被集羣中的多個節點讀到數據緩衝區以後，最近版本的數據塊的位置。
• 數據塊被實例所擁有的模式:
(N) Null空, (S) Shared共享,(X) Exclusive排他
• 數據塊正在被每個實例所擁有的角色:
Local本地或global全局
1.2. RAC同步過程
當一個實例請求一個資源，例如一個數據塊；RAC來管理實例如何獲得這個數據塊。如果這個數據塊被一個或多個節點稍後修改，那麼Oracle執行在一個全局級別的同步，來允許集羣訪問這個共享的數據塊。在這種情況下同步請求內部節點消息來爲讀一致性和在集羣數據庫內傳輸數據塊的拷貝做準備。
當一個或多個實例請求一個被另一個實例更新了的數據塊的時候，全局緩存服務進程（Global Cache Service Processes (LMSn)）定位，準備，並且傳輸最近的數據塊鏡像。GES通過內部連接傳輸內部節點消息來調度GCS處理的過程。
注意：在節點內部oracle利用共享存儲器，所以不需要傳遞消息
儘管如此，在RAC中一些本來的本地調度變成全局調度：當遠程的實例請求本地擁有的資源時候。這尤其是在以下要描述的隊列和以前的數據塊鏡像上。
1.3. 隊列（Enqueues）
隊列是一個內存結構：對應行的一連串更新。只有當另一個實例請求資源的時候隊列才被分配。
你不必配置全局隊列，他們的號是在啓動的時候自動計算出的而且oracle在alert.log文件中記錄了計算出的值。
1.4. 過去的鏡像（Past Images）
過去的鏡像是oracle維護的髒數據塊的拷貝，直到髒數據的版本信息寫完。GCS管理過去的鏡像並且GCS失敗恢復時利用他們。
2. 資源模式和角色
作爲一個內部實例數據塊的傳輸的結果，同樣的數據塊會在多個緩存中存在。數據塊也可以被多個實例擁有在不同模式下，這取決於擁有數據塊的實例是否修改數據或者只是讀裏面的內容。GCS利用模式和角色來調度資源，例如共享數據塊，它們在以下標題中被描述：
資源模式
資源角色
2.1. 資源模式
一個資源模式確定資源擁有者是否能修改這個資源。
全局緩存資源模式
資源模式 標識符 描述
Null N 在這個資源級別下無訪問權限
Shared S 一個保護性讀，當在這個資源級別下實例不可以修改它. 多個實例可以讀這個資源.
Exclusive X 在這個資源級別下, 它授權實例對這個資源進行排他訪問. 其他實例不能寫這個資源. 一致性讀舊資源有可能是依然有效的.（舊資源存在的話）
2.2. 資源角色
Oracle爲擁有這個資源的實例分配一個角色。角色可以是本地或者全局兩者之一。本地到全局角色的轉變按照以下步驟：
當一個數據被一個實例首先讀到了緩存並且其他的實例還沒有讀這個塊，這數據塊是本地管理。GCS因此給這個數據塊分配一個本地角色。
如果這個數據已經被本地實例修改並且傳輸給其他實例，這時它被認爲是全局管理並且GCS給這個數據塊它分配一個全局角色。
如果資源僅存在一個實例中，那麼所有的資源都擁有本地角色。如果一個數據塊在一個實例中被修改並且隨後傳輸到其他實例，然後包含這髒數據塊的緩存被認爲是全局的髒塊並且這個資源擁有了一個全局角色。
2.3. 全局資源服務操作
GCS跟蹤數據塊的位置、模式和角色。GCS因此也管理涉及相關資源的實例對這個資源的訪問權限。Oracle利用GCS來保證緩存一致性，噹噹前版本的數據在一個實例的緩衝區並且另一個實例請求那個數據塊進行修改。
如果一個實例，讀這個數據塊在一個排他模式，那麼在這個實例內多個可以不利用GCS來共享訪問一組數據塊。然而這只是在這個數據塊沒有從本地緩存輸出的情況下才是真實的。如果數據塊已經從本地緩存傳輸出去，然後GCS在全局目錄中更新這個資源爲全局角色；至於這個資源是否從排他模式轉換成其他模式，取決於其他的實例怎樣使用這個資源。
2.4. 全局緩存服務實例
假設集羣中的一個實例需要更新一個數據塊，同時其他的實例也需要更新同樣的數據塊。沒有GCS提供的緩存一致性，倆個實例就可以同時更新同樣的數據塊。
儘管如此，由於GCS控制着這個同步，只有一個實例能更改這個數據塊，另一個實例必須等待。
爲了保證在任何時候僅有一個實例能更新這個數據塊，GCS維護這個緩存一致性。直到實例的事務完成之前，這個實例不必擁有這個數據塊在一個排他模式。
例如：一個實例可以修改一個數據塊中的一行同時另一個實例的事務也在修改同一個數據塊的另一行，但是還沒有提交這個改變。
2.5. 緩存一致性和全局緩存服務
當一個實例修改數據庫中的數據塊之前，GCS保證這個實例是在一個集羣的範圍內獲得一個資源。因此，GCS同步全局緩存訪問，僅允許在一個時間點僅有一個實例能修改這個數據塊。
Oracle的多版本體系結構區別於當前數據塊和一個或多個讀一至性版本的數據塊。當前數據塊包含所有提交的改變和將要被提交的事務。
一個一致性讀版本的數據塊象徵着在一個時間點的數據塊快照。全局服務進程利用回滾段的信息來創建出一致性版本的過去的鏡像。當前和一致性讀的數據塊都被GCS所管理。
如果一個實例請求一個已經被另一個實例更改過的數據塊，那麼擁有數據塊的實例爲這個數據塊維護一個過去的鏡像。在失敗的情況下，oracle可以讀取PI來重新構造出當前的和一致性讀版本的數據塊。
2.6. SCN的處理過程
同步一個集羣內的資源，特別是數據塊，orale必須跟蹤數據塊的連續世代的改變。更確切的說，Oracle爲每個版本的數據塊分配一個數字標識符來記錄這個改變。這使Oracle來產生順序化的重做日誌並且提供給以後的恢復處理。
Oracle使用一個邏輯的時間戳也就是一個系統改變號，來爲每個實例和所有的實例中的數據塊改變事件排序。這主要的SCNs的目的是通過對重做日記的條目進行標記來與恢復過程同步。
Oracle爲每個事務分配一個SCN。從概念上講，這是一個全局內產生的連續的SCNs.實際上。儘管如此，SCNs可以並行的讀和產生。其中一個SCN產生模式叫做Lamport SCN Generation.。
在一個單實例Oracle中，SGA以一個排他模式維護一個已經掛載數據庫的實例中的SCN的增長。在RAC中，SCN必須被全局維護並且通過平臺執行改變。SCN能被GCS通過Lamport SCN generation 模式管理，或者通過硬件時鐘，或者專門的SCN服務器。
2.7. Lamport SCN Generation
Lamport SCN Generation模式是高效和可升級的，因爲它在所有的實例中並行的產生SCNs。在這種模式下，所有實例中的信息都攜帶SCNs。多個實例可以並行的產生SCNs而不需要在實例之間進行額外的通信。
在大多數平臺上，當MAX_COMMIT_PROPAGATION_DELAY參數比平臺指定的閾值大的時候，Oracle利用Lamport SCN Generation模式。一般這個參數代表性的設置成7秒。注意：改變這個值也就改變了你集羣中的SCN發生器。
當實例啓動後，檢查alert.log來確定是否啓用了Lamport SCN generation模式。如果MAX_COMMIT_PROPAGATION_DELAY參數的值比這個閾值小，那麼Oracle使用硬件時鐘SCN產生模式。
3. 緩存熔接全局緩存服務
3.1. 緩存熔接處理過程概覽
默認來說，一個資源被分配給實例緩存的每個數據塊。由於緩存熔接和消除了當其他實例請求修改數據塊時硬盤寫的發生，在實例之間管理共享數據的開銷被大幅減少。緩存熔接的併發控制不僅提高了性能，並且減少了RAC環境中的管理負擔。
緩存熔接專注於以下幾個併發類型：
多節點的併發讀
不同節點的併發讀寫
不同節點的併發寫
3.2. 多節點的併發讀
當兩個節點需要讀同樣的數據塊是發生點節點的併發讀。RAC不必爲了解決這個情況進行同步，因爲在沒有緩存一致性衝突的情況下，多個實例可以讀這個共享的數據塊。
3.3. 不同節點的併發讀寫
當一個實例請求讀的數據塊已經被另一個實例修改並且還沒有寫到磁盤上，這個請求可以是當前版本的數據塊或是一致性讀的數據塊，在這種情況下，全局緩存進程通過內部連接把數據塊從擁有數據塊的實例緩存中傳輸到請求實例的緩存中。
3.4. 不同節點的併發寫
不同節點的併發寫發生在不同的實例修改相同的數據塊。在這種情況下，把持實例完成它的工作之前需要收到一個關於該數據塊的請求，GCS然後轉換這個數據塊的資源爲全局管理模式並且LMSn給請求實例傳輸一個數據塊的拷貝。這個過程的主要情節如下：
GCS跟蹤每一個版本的數據塊，並且每個版本就是提到的一個過去的鏡像（PI）.萬一失敗，Oracle利用PI的信息來重建當前版本的數據塊。
這緩存到緩存的傳輸通過高速的IPC內部鏈接完成，因此避免了磁盤I/O。
緩存熔接限制了上下文交換的數量，因爲它簡化了往返信息。減少上下文交換的數量是緩存一致性協議的效率更加高效。數據庫寫進程不影響緩存熔接數據塊的傳輸。
3.5. 寫協議和過去的鏡像跟蹤
當一個實例爲了修改而請求一個數據塊的時候，LMSn從最後一個修改數據塊的實例中發送該塊到請求的實例。此外，LMSn進程在最初的把持例中保留一個這個數據塊的PI。
只有緩存復位和執行檢查點期間才觸發寫盤。例如，考慮這種情況,一個實例發起一個寫數據塊的動作並且這個數據塊擁有全局角色。但是，這個實例僅僅擁有該塊以前的鏡像並且在緩存中不是最當前的。綜合以上情況，這個實例通知GCS，GCS給把持最當前數據塊的實例發送寫請求。然後把持實例給GCS發送一個完成信息。最後，所有的實例清空這個數據塊的PI。
3.6. 資源控制, Cache-to-Cache 傳輸, 緩存一致性
GCS爲讀到實例高速緩存裏的數據塊分配和打開資源。當資源不再管理任何緩存或者由於緩存替換而觸發寫盤的時候，oracle關閉資源。當Oracle關閉一個資源，它把這個資源返回給Oracle能分配新資源的資源列表中。
3.7. 塊訪問模式 和緩存狀態
一個另外的併發控制概念是緩存狀態：一個實例中的本地緩存的緩存狀態。
緩存的狀態涉及到數據塊的訪問模式。例如，如果一個緩存的狀態是排當前，一個實例擁有這個資源在排他模式。
查看緩存的狀態，查詢V$BH中的STATUS列，V$BH視圖提供數據塊的狀態，關於數據塊的訪問模式和它們的緩存狀態的名字如下：
NULL-CR:一個實例可以對這個數據塊執行一致性讀，也就是說，如果這個實
例擁有一個老版本的數據塊。
S-SCUR：一個實例已經共享的訪問數據塊並且只能執行讀。
X-XCUR：一個實例有排他的訪問數據塊並且能修改它。
NULL-PI：一個實例改變了這個數據塊但是爲了記錄以前的狀態而保留了以前鏡像。
只有SCUR和PI緩存狀態是RAC指定的。在任何時候的RAC裏只有一個數據塊的拷貝狀態是XCUR狀態。去執行修改數據塊的時候，必須爲包含數據塊的緩存分配一個XCUR狀態。
例如，如果其他的實例請求訪問最當前版本的數據塊，那麼Oracle改變訪問模式從排他到共享，發送一個當前讀版本的數據塊給請求的實例，並且保存一個PI緩存，如果這個緩存包含一個髒數據塊。
在這一點上，第一個實例有當前讀版本數據塊並且另一個實例也擁有當前數據塊在共享模式。因此，這資源的角色變成全局。這樣在任何時刻多個SCUR版本的數據塊通過RAC被緩存起來。
4. 緩存熔接設想
以下的設想舉例說明了緩存熔接處理過程的關鍵點。這些設想沒有指出所有的配置。例如，這個設想沒有描述讀一致性。這節中的設想是：
爲了修改請求一個改變的塊
向磁盤寫數據塊
4.1. 爲了修改操作請求一個改變的塊
圖4-1的設想數據塊已經被修改，或者髒的，僅有一個實例以排他模式(X)把持它.此外，這個情節假定實例訪問的數據塊已經改變。也就說，它在集羣範圍內只有一份拷貝。換句話說，這數據塊擁有一個本地角色。
1. 實例1試圖修改這個數據塊，給GCS提交一個請求。
2. GCS傳輸這個請求給把持者實例2。
3. 實例2收到這條消息並且LMS進程發送數據塊給實例1.發送數據塊之前，實例2中的資源從排他降級爲NOLL模式並且實例2以PI的形式保留髒塊的緩存。這個角色轉換爲全局，因爲數據塊可能在多個實例中變髒了。與數據塊一起，實例2與請求的實例通信來告知實例2擁有一個NOLL模式的PI。在這同一消息中，實例2也指定請求者保持這數據塊在排他（X）模式和擁有一個全局角色。
4. 當收到這個數據塊，實例1通知GCS它把持這個數據塊在全局角色的排他模式。注意在資源授權給實例1之前，數據塊不會被寫到磁盤裏。
4.2. 寫數據塊到磁盤
圖4-2的場景舉例說明一個實例怎樣處理由於請求空閒的緩衝區時在任何時候執行檢查點或者替換高速緩衝器中的緩存。因爲集羣中的實例的高速緩衝器中存在多個版本的改變的數據塊，被GCS管理的寫協議確定只有最當前版本的數據塊被寫到磁盤裏。它也確保所有以前的數據塊從其他的高速緩衝器中刪除。一個寫請求可以在擁有當前的或者過去的鏡像的任何一個實例上發生。在這個場景中，假設這實例把持一個過去的緩衝的鏡像在NOLL模式請求，Oracle請求把這個緩衝寫到磁盤上。
1. 實例2發送一個寫請求給GCS。
2. GCS轉發這個請求個實例1-當前塊的把持者。
3. 實例1收到這個寫請求而且把這個數據塊寫到磁盤裏。
4. 實例1把這個完成記錄發給GCS然後通知GCS這個資源角色可以變成本地，因爲實例1寫入了當前的塊。
5. 收到這給通知後，GCS命令所有的PI把持者刪除，或者清空它們的PIs；恢復不在需要PIs.緩衝區釋放並且以前擁有的NOLL模式被關閉。
4.3. RAC恢復和緩存熔接
在RAC恢復過程中，恢復進程的數量與失敗節點的數量是成比例的。一般來說數據塊恢復完成後很快變成有效。
當一個實例失敗或者失敗者是被另一個實例刪除的，Oracle執行以下恢復步驟：
1. 在恢復過程中，第一個階段就是GES重配置，Oracle首先重新配置GES隊列。然後Oracle重新配置GCS資源。在這時候，所有的GCS資源請求和寫請求被臨時暫停。儘管如此，進程和事務能繼續修改數據塊，只要那些進程和事務已經申請到需要的隊列。
2. GES控制的隊列重新配置完成後，一個日誌讀和GCS資源重製並行發生。在最後一步，恢復的數據塊所需的資源已經確定了。
3. 恢復所需的緩存空間和從先前正在讀的日誌中獲取恢復所需的資源。然後，假定被恢復的PI在集羣數據庫中其他緩存中，從其他實例中請求緩存資源。從恢復緩衝區的起點被分配一個特殊的鎖。
4. 爲下一步操作所需的所有的資源和隊列請求在全局資源目錄中，開始釋放。任何不需要回復的數據塊現在可以被訪問了。注意系統已經可以部分可用了。
5. 在第二步確定的在緩存中需要恢復的和需要寫入的每個數塊，恢復數據塊後立即釋放恢復資源，這樣高速緩衝器恢復處理的數據塊更多的數據塊變成可用。
6. 當所有的數據恢復完成並且恢復資源已經被釋放，系統再次變成完全可用。恢復的數據塊在恢復完成後已經可用了。
概括來說，在完全恢復數據庫之前，恢復的數據庫或者恢復的部分數據庫已經變成可用狀態了。這使得系統儘早的可用並且使恢復變成可升級的。
如果在依然存在的實例的PI緩衝器中沒有任何數據塊，然後Oracle爲失敗的實例執行一個日誌合併，日誌合併的性能開銷取決於失敗實例的節點數和日誌的大小。因此你可以利用檢查點的特性控制重做日誌。在它的高級規劃，RAC可以恢復可以處理多個同時發生的失敗和一連串的失敗。共享服務的特性也爲實例失敗恢復提供了彈性。
5. 通過全局隊列服務調度資源
這章描述了GES在集羣RAC中如何執行內部實例資源調度消息。GES調度的內部實例包括資源，數據和內部實例數據請求。總體包括：
全局隊列服務處理過程
全局隊列併發控制
通過GES管理資源
5.1. 全局隊列服務處理過程
GES管理所有的非緩存熔接的內部實例資源操作和跟蹤所有的Oracle隊列機制的狀態。GES爲一個以上的實例管理資源。GES控制的主要資源是字典緩存鎖和庫緩存鎖。GES管理的關於實例之間的資源進行的通信。儘管如此，那些資源不保護數據文件塊。GES也執行探測所有的對死鎖敏感的隊列和資源。
5.2. 全局隊列併發控制
Oracle數據庫的其他部分也全局保護他們的數據結構。這些部分包括：
數據字典訪問層
庫緩存層
傳輸管理代碼層
每個層都有指定的協議來讓其他層訪問他們各自的數據結構。Oracle所有的層使用GES API的服務來訪問，轉變，釋放在他們層上的資源。當一個實例啓動的時候，GES使用影響全局隊列資源的參數爲隊列資源管理操作自動計算所要求的內存。
在傳輸層，全局隊列資源有時存在的時間非常短而且快速的釋放。一般來說，例如當事務開始的時候有一個TX鎖，提交的時候隨即釋放。有些情況下，它被用作事件的信號，例如像這種情況，執行DDL語句的時候庫緩存鎖可能是庫緩存對象無效。一般來說，事務和表鎖的處理過程在RAC和單實例中是一樣的。下一節進一步的測試GES管理的資源。
5.3. 全局隊列管理的資源
這節解釋Oracle怎樣利用GES的排隊功能，來管理爲RAC環境中事務，表和其他實例併發的資源。以下的資源位於單實例的數據庫，但是在全局被GES控制。
字典緩存鎖
庫緩存鎖
5.4. 字典緩存鎖
每個RAC數據庫實例有一個字典緩存，或者行緩存，包含數據字典信息。數據字典的結構在RAC中和在單實例中是一樣的。儘管如此，在一個RAC中，Oracle在集羣中同步所有的字典緩存信息。就像在單實例數據庫中，RAC也是利用栓鎖來做這些事情。
考慮在一個5個節點環境的RAC中，用戶刪除在一個節點上刪除了一個表。因爲5個節點有5份字典緩存，當節點刪除表的時候，它的緩存必須通知其他4節點的字典緩存刪除這個表的定義。RAC利用GES自動管理這些信息。
5.5. 庫緩存鎖
當一個數據庫對象，例如表，視圖，過程，包或索引，被SQL,DML.DDL，PL/SQL或者JAVA語句引用的時候，語句分析需要給他們進行加鎖。在Oracle9i，Oracle加鎖直到解析和編譯完成或者解析調用。