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)
object master_instance_id
T1 1
T2 2
T3 1
idx_t1 2
...

每個例項只會維護該例項所master的那些資源的GRD記錄。
比如例項1裡記錄的GRD的資料就是T1,T3等的GRD的記錄。
obj# file# block# instance .....
T1 100 2000 2
T1 100 1456 1
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（記憶體融合）了