共計 4565 個字符，預計需要花費 12 分鐘才能閱讀完成。

這篇文章主要介紹“怎么理解并掌握 RAC”，在日常操作中，相信很多人在怎么理解并掌握 RAC 問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么理解并掌握 RAC”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學習吧！

理解 redo 共享了和 redo 單個 sequence 里面的 scn 不連續，就會明白為什么 RAC 到 RAC 的恢復或 RAC 到單機的恢復，一般都是 recover 到某個 thread 的某個 scn 或 sequnce 就可以了

數據庫是否 RAC 就是看參數 cluster_database

RAC 區別于單機的一個就是多了一個 GRD（global
resource directory）內存區以及附屬的多個后臺進程和部分數據庫文件，GRD 里記錄的是每一個數據塊在集群間的分布圖，它位于每一個實例的 SGA 的 shared pool 中，但是每個實例都是部分 GRD，所有實例的 GRD 匯總在一起就是一個完整的 GRD。該區域用來存儲同一個數據庫在不同節點上的分布，即多個實例在并發操作一個數據塊時，將該數據塊存儲在各自實例的 GRD 內存區中。

GRD 可以想像為一張大分區表，每個實例都是分區表中的分區。

GRD Master：每個被調入內存的對象，包括表，索引，cluster 等，都會被分配一個 master 實例。
GRD Master 本身也是一張表：(V$GCSHVMASTER_INFO、V$GCSPFMASTER_INFO、V$HVMASTER_INFO)
objectmaster_instance_id
T11
T22
T31
idx_t12
…

每個實例只會維護該實例所 master 的那些資源的 GRD 記錄。
比如實例 1 里記錄的 GRD 的數據就是 T1,T3 等的 GRD 的記錄。
obj#file#block#instance…..
T110020002
T110014561
T2….

每個實例都有一份完全一樣的拷貝的 GRD Master 表。
這個 master 表記錄的是數據庫對象，不是數據庫的某行某塊

RAC 實例訪問的形象理解 1：比如 master 表記錄中沒有關于數據庫對象表 1 的記錄
實例 1 去訪問表 1 的某行對應的塊，發現 master 表中沒有表 1，也就是表 1 從來沒有訪問過，這樣數據庫就在 master 表中記錄表 1 的 master 為實例 1
RAC 實例訪問的形象理解 2：比如 master 表記錄的數據庫對象表 1 的 maser 是實例 2
實例 1 去訪問表 1 的某行對應的塊，實例 1 去訪問實例 2，實例 2 發現這個塊不在 GRD 中，就告訴實例 1 這個塊不在 SGA 中，實例 2 讓實例 1 去走 IO 訪問磁盤
實例 1 去訪問表 1 的某行對應的塊，實例 1 去訪問實例 2，實例 2 發現這個塊在 GRD 中并且就在自己的 SGA 上，實例 2 把這個塊的副本發送給實例 1
實例 1 去訪問表 1 的某行對應的塊，實例 1 去訪問實例 2，實例 2 發現這個塊在 GRD 中并且在實例 3 上，實例 2 告訴實例 1 這個塊在實例 3 上，并且實例 2 讓實例 3 把這個塊的副本發送給實例 1

2 way 和 3 way 是指要跳幾個節點  
只有兩節點的 RAC 不可能出現 gc current 3-way，兩節點，某個數據塊不在自己這里就在對方那里

本節點去訪問 resource MASTER 節點
2-way: resource MASTER 和 cached 節點在同一個節點。
3 way: 就是多一個節點，resource MASTER 和 cached 節點不是同一個節點

RAC 提高性能的理解：負載不足導致 sql 執行很慢時，多個實例可以分攤負載（CPU、內存），負載不是性能瓶頸的情況下，RAC 無法提高具體的 sql 的執行效率，相反實例越多，具體的單個 SQL 的性能越差。

實例越多性能越差的理解：比如 10 個節點，實例 A 要訪問 100 個塊，其中 10 個塊在節點 1，10 個塊在節點 2.。。10 個塊在節點 10，這樣 100 個塊，就要訪問 1 次 master，master 再告訴塊具體在哪個節點，這些節點再把塊推送到實例 A，這樣就需要 1 次實例到 master 的訪問 +10 次 master 到各個節點的訪問 +10 次各個節點推送塊到節點 A，總計 11 次的訪問 +10 次的 GC 塊傳輸

RAC 的本質是一個數據庫，運行在多臺計算機上的數據庫，它通過 Distributed Lock Management(DLM: 分布式鎖管理器) 來解決并發問題。因為 RAC 的資源是共享的，為了保證數據的一致性，就需要使用 DLM 來協調實例間對資源的競爭訪問。RAC 的 DLM 就叫作 Cache Fusion（內存融合）。

Cache Fusion 是通過高速的 Private
Interconnect，在實例間進行數據塊傳遞，它是 RAC 最核心的工作機制，它把所有實例的 SGA 虛擬成一個大的 SGA 區，從而使得多個節點 SGA 對用戶透明。每當不同的實例請求相同的數據塊時，這個數據塊就通過 Private Interconnect 在實例間進行傳遞。以避免首先將塊推送到磁盤，然后再重新讀入其他實例的緩存中這樣一種低效的實現方式。當一個塊被讀入 RAC 環境中某個實例的緩存時，該塊會被賦予一個鎖資源（與行級鎖不同），以確保其他實例知道該塊正在被使用。之后，如果另一個實例請求該塊的一個副本，而該塊已經處于前一個實例的緩存內，那么該塊會通過 Private Interconnect 直接被傳遞到另一個實例的 SGA。如果內存中的塊已經被改變，但改變尚未提交，那么將會傳遞一個 CR 副本。這就意味著只要可能，數據塊無需寫回磁盤即可在各實例的緩存之間移動，從而避免了同步多實例的緩存所花費的額外 I /O。這樣對用戶而言 cache fusion 就把多個實例的數據庫緩沖區虛擬成一個數據庫緩沖區，它實現了 SGA 對用戶透明。很明顯，不同的實例緩存的數據可以是不同的，也就是在一個實例要訪問特定塊之前，而它又從未訪問過這個塊，那么它要么從其他實例 cache fusion 過來，或者從磁盤中讀入。整個 Cache Fusion 有兩個服務組成：GCS 和 GES。GCS 負責數據庫在實例間的傳遞，GES 負責鎖管理。Cache Fusion 要解決的首要問題就是：數據塊拷貝在集群節點間的狀態分布圖，這是通過 GRD 實現的。

要發揮 Cache
Fusion 的作用，要有一個前提條件，那就是互聯網絡的速度要比訪問磁盤的速度要快！否則，沒有引入 Cache Fusion 的意義。

GCS/GES

Global Cache Service 全局緩存服務(GCS): 要和 Cache Fusion 結合在一起來理解。全局緩存要涉及到數據塊。全局緩存服務負責維護該全局緩沖存儲區內的緩存一致性，確保一個實例在任何時刻想修改一個數據塊時，都可獲得一個全局鎖資源，從而避免另一個實例同時修改該塊的可能性。進行修改的實例將擁有塊的當前版本（包括已提交的和未提交的事物）以及塊的前象 (post image)。如果另一個實例也請求該塊，那么全局緩存服務要負責跟蹤擁有該塊的實例、擁有塊的版本是什么，以及塊處于何種模式。GCS 對應進程 LMSn(processes global cache fusion requests)

Global Enqueue Service 全局隊列服務 (GES)：主要負責維護字典緩存和庫緩存內的一致性。字典緩存是實例的 SGA 內所存儲的對數據字典信息的緩存，用于高速訪問。由于該字典信息 存儲在內存中，因而在某個節點上對字典進行的修改（如 DDL) 必須立即被傳播至所有節點上的字典緩存。GES 負責處理上述情況，并消除實例間出現的差異。
處于同樣的原因，為了分析影響這些對象的 SQL 語句，數據庫內對象上的庫緩存鎖會被去掉。這些鎖必須在實例間進行維護，而全局隊列服務必須確保請求訪問相
同對象的多個實例間不會出現死鎖。GES 對應進程 LMON(issues heartbeates and performs recovery)

RAC 的一些等待事件

gc buffer busy

即 global cache buffer busy，產生的原因和單實例的 buffer busy waits 類似，就是一個時間點節點 a 的實例向節點 b 請求 block 的等待。主要是修改操作引起，而非讀引起。

11g 開始 gc buffer  busy 分為 gc buffer busy acquire 和 gc buffer busy release。

產生原因：熱塊，低效 sql（越多的數據塊請求到 buffer cache 中，那么越可能造成別的會話等待。）數據交叉訪問（RAC 數據庫，同一數據在不同數據庫實例上被請求訪問）所以 RAC 建議不同的應用功能在不同的數據庫實例上被訪問

gc buffer busy acquire 是當 session#1 嘗試請求訪問遠程實例(remote  instance) buffer，但是在 session#1 之前已經有相同實例上另外一個 session#2 請求訪問了相同的 buffer，并且沒有完成，那么 session#1 等待 gc buffer busy acquire。

gc buffer busy release 是在 session#1 之前已經有遠程實例的 session#2 請求訪問了相同的 buffer，并且沒有完成，那么 session#1 等待 gc buffer busy release。

gcs log flush sync

GCS 日志刷新同步

flush 是 Oracle 為了保證 Instance Recovery 實例恢復機制，而要求每一個 current block 在本地節點 local instance 被修改后(modify/update) 必須要將該 current block 相關的 redo 寫入到 logfile 后（要求 LGWR 必須完成寫入后才能返回)，才能由 LMS 進程傳輸給其他節點使用。

The cause of this wait event gcs
log flush sync is mainly – Redo log IO performance.

RAC 使用分布鎖管理（DLM）機制對并發進行檢測，用一個例子說明 DLM 作用

（1）  一個 2 節點的 RAC

（2）  節點 1 想要修改數據 1

（3）  節點 1 向 DLM 請求，DLM 發現數據 1 還沒有被任何節點使用，DLM 就授權給節點 1；并且 DLM 登記節點 1 對數據 1 的使用

（4）  節點 2 也想修改數據 1

（5）  節點 2 向 DLM 請求，DLM 發現數據 1 被節點 1 使用，DLM 就會請求節點 1“先給節點 2 用吧”，節點 1 接到請求后釋放其對數據 1 的占用，節點 2 能夠操作數據 1

（6）  DLM 記錄這個過程

需要強調的是 DLM 負責的是節點間的協調，而節點內的協調不是 DLM 負責，繼續上面這個例子

（1）  現在節點 2 的進程 1 修改數據 1

（2）  節點 2 的進程 2 也想修改數據 1

（3）  節點 2 仍然請求 DLM，DLM 發現節點 2 現在已經有權限，無須授權

（4）  進程 2 對 DLM 的請求被通過，但是進程 2 是否能夠修改數據 1，還需要進一步檢查

（5）  通過傳統的鎖模式，比如“行級鎖”，進程 2 發現數據 1 正被進程 1 修改，所以進程 2 只能等待

所以學習 RAC 就是學習 DLM，也就是 Cache Fusion（內存融合）了

RAC 集群實現并發機制過程：

到此，關于“怎么理解并掌握 RAC”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注丸趣 TV 網站，丸趣 TV 小編會繼續努力為大家帶來更多實用的文章！