怎么理解并掌握RAC

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

理解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”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！