RAC

在Grid Infrastructure安裝完以後，我們把注意力轉移到叢集上的Oracle軟體的安裝上來。我們看到，Grid Infrasctructure提供了執行RAC的框架，包括叢集通訊連結、節點分離、節點成員關係等服務。ASM是Oracle儲存資料庫的首選方式。RAC利用這些概念並擴充套件了需要的基本服務。

安裝選項

成功安裝了Grid Infrastructure/Clusterware以後，Oracle Universal Installer檢測到叢集環境的建立，然後提供安裝整個叢集上或是使用者指定其中幾個節點的RAC選項。使用叢集檢驗工具cluvfy來為RDBMS的安裝檢測是否滿足先決條件是良好的做法。和安裝叢集一樣，Oracle Universal Installer將首先在第一個節點上對軟體進行複製和連結，然後將Oracle主目錄push到指定的其他節點中。和Grid Infrastructure不同的是，Oracle RDBMS可以被安裝在共享檔案系統上(例如OCFS2或ACFS上)，在叢集中增加新節點被簡化，因為不需要在新的節點上重新安裝軟體，打補丁同樣被簡化了--只有一個Oracle主目錄需要打補丁。但是補丁不能以rolling方式安裝，因此停機時間不可避免。

在安裝過程中，Oracle Universal Installer將提醒管理員安裝或升級資料庫，或只安裝軟體。如果安裝的時候有新的版本釋出，那麼僅僅安裝軟體，打補丁升級後再建立資料庫是比較好的做法。

單例項和RAC資料庫

RAC和單例項資料庫在很多重要方面都有所不同。

在RAC中，一個資料庫在共享儲存中為多個伺服器上的例項所訪問。資料庫檔案、線上redo檔案、控制檔案和伺服器引數檔案(spfile)都必須共享。此外，閃回日誌、已歸檔的redo日誌、資料泵轉儲檔案、和dataguard broker配置檔案也可以共享，根據你的配置來決定(這是可選的，但還是強烈建議這麼做)。在使用ASM的時候，你同樣可以在每個RAC的節點中找到一個本地的pfile檔案，這個檔案指向對應磁碟組中的spfile。另一個儲存在本地的檔案是Oracle密碼檔案。叢集檔案系統中的使用者常常把這些檔案放在一個共享的位置，透過符號連結指向$ORACLE_HOME/dbs

資料庫檔案

資料庫檔案包含資料庫中的所有資料，包括表、索引、資料字典和經過編譯的PL/SQL程式碼，不勝列舉。在RAC中，每個資料檔案都只有一個複製，位於共享儲存中，併為所有例項所訪問。Oracle預設不為資料檔案提供映象，大部分使用者選擇在儲存層面來做冗餘，避免介質故障導致的資料丟失。在儲存陣列沒有這個功能時，可以使用Oracle ASM來提供冗餘。

控制檔案

控制檔案儲存資料庫的物理結構的相關資訊，包括它們的狀態。如果你使用RMAN且沒有專門的RMAN catalog資料庫，控制檔案中也可以儲存RMAN備份的資訊。在單例項資料庫和RAC中，控制檔案應該做映象以防止損壞或儲存故障。當同時使用ASM和閃回恢復區時，會自動做多路複用。預設情況下，Oracle在db_create_file_dest和db_recovery_file_dest指定的磁碟組中對控制檔案做多路複用。這種情況下，若你使用spfile，control_files引數將自動更新。要知道控制檔案會成為RAC中的一個爭用點，因為它們會被頻繁更新。因此不要對控制檔案做過多的映象複製，而且應該把它們放置在高速儲存上。

REDO和歸檔

在RAC中，每個例項有它自己的聯機日誌檔案，稱為執行緒(thread)。執行緒的資訊可以在V$LOG和相關的檢視中檢視。
每個執行緒中你需要兩組redo日誌，而且若沒有使用ASM和閃回恢復區，你應該考慮手動對組中的成員做多路複用。由spfile負責例項和執行緒間的對映(透過初始化引數thread)。當新增一個新的例項到叢集中時，就需要一個相應的redo執行緒，這可以使用兩種方式來做到：第一種，執行SQL語句alter database add logfile group x thread y; 第二種，在使用策略管理的資料庫(policy-managed)中，會自動建立。然後由Oracle來啟用。
lgwr後臺程式將redo buffer重新整理到redo log中。online redo log需要放在高速儲存中，否則它可能會成為一個爭用的點，特別是在一個高頻率提交的系統中。通常對設計不合理的應用的最佳化是減少commit的頻率，並至少將redo log和控制檔案移到高速儲存中，以減少一些效能瓶頸。在日誌切換頻繁的系統中，增加每個執行緒的重做日誌組數會有所幫助，它能給歸檔程式更多的時間來歸檔redo日誌。這種方法在歸檔程式需要將歸檔的redo傳送到standby資料庫中時也能獲益，但是，現在的大部分系統採用Log Network Service(LNSn)程式來非同步傳送redo給standby資料庫的Remote File Server(RFS)程式。在Oracle 10.2和11.1中，每個destination有一個LNS程式，到了11.2，LNSn程式被NSSn何NSAn後臺程式所代替。NSSn程式被用來同步傳送redo，NSAn用來非同步傳送redo。redo log大小設定的原則是，日誌切換不會太頻繁(AWR和statspack能夠幫助定義一個合適的大小)。Oracle 11.2還允許管理員來選擇redo log的塊大小，現代儲存單元使用4kb扇區大小代替了原先的512b。
當RAC中的一個例項發生故障，所有執行緒被合併來幫助建立恢復集，由伺服器監控程式來執行前滾或回滾操作。
在lgwr程式將一個redo log寫滿以後，其中一個歸檔程式會將該檔案複製到指定的目錄中。
閃回恢復區在Oracle 10.1中引入，看是來是歸檔日誌的最佳存放位置。如果你沒有使用閃回恢復區，建議將歸檔日誌放在一個共享檔案系統中，以便每個節點都可以訪問到。與單例項資料庫不同，RAC需要所有執行緒的歸檔日誌。當一個例項執行介質恢復時，你可以從它的alter日誌上看到，Oracle使用了每個執行緒的所有日誌檔案。

Undo表空間

和redo執行緒類似，每個叢集資料庫的例項由它自己的undo表空間。spfile中配置了例項和undo表空間之間的一對一對映關係。但這個對映並不代表該undo表空間就長期繫結在該例項上，所有的其他例項同樣可以訪問該undo表空間來建立塊的讀一致前映象。

當新增一個例項到叢集中時，需要新增新的undo表空間並對映到該例項，和redo log一樣。在policy-managed資料庫中，Oracle可以自己來做這件事。

雖然還是可以使用手動的undo管理，但是強烈建議使用自動undo管理(AUM)。

RAC資料庫的儲存選項

管理員可以在如下的選項中選擇：

ASM 這是Oracle的首選儲存選項，而且是RAC標準版中支援的唯一配置
OCFS2
裸裝置不推薦使用，不僅是因為被新版的linux核心棄用，在Oracle 11.2中同樣不支援
網路檔案系統(NFS)
Red Hat Global File System 只在紅帽和Oracle Enterprise Linux中支援，可以用在閃回恢復區和資料庫檔案上

RAC例項

一個RAC資料庫包含2個或更多的例項，一般每個例項都在不同的節點上，由一些共享記憶體結構和後臺程式組成。

每個例項都有自己的SGA，在例項啟動的時候分配。Oracle在10g中引入了自動共享記憶體管理(ASMM)，在11g中引入了自動記憶體管理(AMM)。但是AMM與linux的大頁面不相容，這對大記憶體的系統來說是個問題。

Oracle需要同步訪問本地共享記憶體和整個叢集。所有例項都能訪問其他例項的SGA。

在RAC中Oracle核心對共享記憶體的保護措施和單例項中是一樣的，同樣使用了閂和鎖。閂是一個低階別、輕量級的序列裝置。請求閂的程式不會排隊，如果程式不能獲得閂，它就會進入spin狀態。spin的意思是，這個程式會進入一個緊密迴圈來預防被作業系統的排程程式從CPU中取下。如果一個程式長時間得不到閂，它會進入睡眠，在一個時間間隔後再次嘗試申請。閂是例項級別的，沒有叢集範圍的閂。

另一方面，鎖在更長的時間請求一次，比閂更為複雜。鎖可以是共享或獨佔的，請求鎖的程式以先進先出(FIFO)的機制來等待，由佇列來控制鎖的訪問，這個佇列是叢集範圍內的。

快取一致性的需求意味著鎖和閂在RAC中比單例項要更加複雜。和單例項中一樣，對buffer cache中資料庫的訪問和佇列必須在本地例項中管理，但是，遠端例項的訪問也需要管理。因為這個原因，Oracle使用全域性資源目錄(GRD)和一些額外的後臺程式。

(Oracle將V$檢視加上例項標識組合起來形成GV$檢視，一個GV$檢視包含了叢集中所有例項的動態效能檢視)

全域性資源目錄 (GRD)

RAC中使用了一些附加的後臺程式來做快取間的同步——記住RAC使用cache fusion結構來模擬一個橫跨叢集內所有節點的全域性SGA。訪問buffer cache中的塊需要在讀一致和寫的訪問間進行協調，共享資源的佇列現在也是在叢集全域性上的。全域性快取服務(Global Cache Service GCS)用來對公共buffer cache的訪問，全域性佇列服務(Global Enqueue Service GES)用來管理叢集中的佇列。

GCS和GES對應用而言都是透明的。內部使用的原結構就是先前提到的GRD，由GCS和GES程式來維護。GRD分佈在叢集的所有節點上，是SGA的一部分，這就是為什麼一個RAC資料庫的SGA比同等情況下的單例項資料庫要來得大。資源管理由GCS和GES來協商。特定的資源完全由一個例項來管理，這個例項就是resource master。但它並是不固定的，Oracle 9.2以後的版本實現了動態的資源管理(DRM)，在9.2以前，資源的remastering只發生在例項故障、GRD重建的時候。新的版本中，如果Oracle檢測到一個resource master以外的例項在一個給定的時間間隔中對一個特定的資源的訪問過於頻繁，就會發生resource mastering。在這種情況下，該資源就會被remaster到其他節點上，也就是說，頻繁訪問該資源的另一個節點將成為resource master。很多使用者反饋了動態remastering的一些問題，當它過於頻繁發生的時候會造成一些不必要的開支。這種情況下，可以禁用DRM。
（GRD還記錄了哪些資源由哪些例項來管理，當一個例項發生故障時，恢復起來將非常方便）

下圖說明GCS如何與GES協同工作來維護GRD

全域性快取服務(GCS)

LMSn後臺程式使用GCS在全域性buffer cache中維護快取的一致性，SGA中可以存在同一個資料塊的多份複製(當前版本只有一個)，GCS對資料塊的狀態和位置進行跟蹤，並透過內部連線將塊傳輸到其他節點的例項中。

全域性佇列服務(GES)

和GCS類似，GES工作在塊級別，管理叢集中的全域性佇列。根據經驗，如果一個操作沒有涉及在全域性buffer cache中控制/移動資料塊，那麼很可能是經過了GES的處理。全域性佇列服務負責所有的例項中的資源操作，比如對資料字典和庫快取的訪問或事務的全域性管理。它同樣可以檢測叢集中的死鎖。它跟蹤多個例項同時訪問資源時Oracle佇列機制的狀態。全域性佇列服務監控(LMON)和全域性佇列服務後臺程式(LMD)組成全域性佇列服務的一部分。鎖程式LCK0負責無快取方式的訪問，比如library和row cache請求。

快取融合(Cache Fusion)

快取融合是例項間資料傳送的最新演變。Oracle 8i中曾使用block ping的機制，作為替代，Oracle使用高速的內部連線來為所有節點間的讀寫轉移資料塊。

例項間使用block ping方法來轉移資料塊代價是很昂貴的，它建議你將工作量與例項聯絡在一起來使例項間的資料塊轉移達到最少。在Oracle並行伺服器(Oracle Parallel Server)中，當一個例項請求一個資料塊來進行修改，而這個資料塊當前正由別的例項所持有，它將發出一個訊號給持有該塊的例項，使其將塊寫入到磁碟，再發回該塊已經可讀的訊號。這種方法的通訊和對磁碟的讀寫操作的量很不盡如人意。

快取融合的塊轉移依賴於全域性資源目錄，不需要超過3次跳躍(hop)，這與安裝及節點的個數有關。很明顯，如果一個叢集只有兩個節點，那麼有一個雙向的快取轉移。如果多於2個節點，將跳躍數限制在3次是必要的。Oracle使用專用的等待事件來衡量涉及快取的通訊，根據實際情況來決定做一個雙向或是三向的快取轉移。

當一個例項透過快取融合來請求一個資料塊時，它首先與資源的master聯絡來確定這個資源的當前狀態，如果這個資源沒有正在被使用，那麼它可以透過從本地磁碟讀取以獲得這個塊。如果這個資源正在被使用，那麼該資源master將把這個資源傳遞到發出請求的例項中。如果這個資源緊接著收到1個或多個例項的修改請求，將會把該資源新增進GRD，資源的master、請求者和持有者都可以不同，這種情況下最多需要三次跳躍來獲得這個塊。

上面提到的雙向和三向的塊轉移與資源的管理方式有關。當資源的master持有被請求的資源，那麼對資料塊的請求就能馬上得到滿足並開始塊的傳輸，這就是雙向的通訊。在三向的情況中，請求者、master和持有者都不相同，那麼該資源master需要轉發這個請求，引發了新的跳躍。

從剛才的討論中，你可以知道在全域性buffer cache中對塊和它們影像間協調是不能低估的。在RAC資料庫中，快取融合常常代表了最大的利益和最高的成本。好處是快取融合理論上執行按比例增大，並可能取得近乎線性的擴充套件性。然而，快取融合強加的額外工作量可能會在10%-20%的範圍內。

讀一致性

Oracle資料庫的主要特徵之一就是能同時提供不同視野下的資料，這個特徵叫做多版本讀一致。查詢是讀一致的，寫不會阻塞讀，反之亦然。當然，多版本讀一致對RAC一樣有效，但涉及到一點其他的工作。

System Change Number(SCN)是一個Oracle的內部時間戳，對讀一致非常重要。如果本地例項請求一個塊的讀一致版本，它需要聯絡這個塊的resource master來確定這個塊是否有相同SCN的版本，或者更新的版本存在於某個遠端例項的buffer cache中。如果這個塊存在，那麼resource master會傳送請求給相應的遠端例項來轉發這個塊的讀一致版本給本地例項。如果遠端例項持有這個塊的請求時間SCN的版本，那麼它會馬上傳送這個塊。如果遠端例項持有的是這個塊更新的版本，它將建立這個塊的複製（稱為前映象），並對這個複製應用回滾使其回到對應的SCN的狀態，然後將其透過內部連線傳送。

System Change Number(SCN)

SCN是Oracle資料庫產生和使用的內部時間戳，資料庫中發生的所有事件都以SCN標記，事務也一樣。Oracle的讀一致嚴重依賴於SCN和undo表空間中的資訊。SCN需要在叢集中同步，RAC中用來使SCN在所有節點間通用的方案有兩個：broadcast-on-commit和Lamport。

broadcast-on-commit是10.2以後的預設方案，它解決了Lamport方案的一個問題：在以前，這個預設方案是Lamport，它承諾了更好的擴充套件性，讓SCN像叢集其他通訊一樣來傳播，但並不是在一個節點中commit後馬上發生。這在大部分情況下都能滿足要求，但是，Lamport方案有一個問題：一個節點的SCN相對另一個節點的SCN有延時是可能的，特別是在在訊息傳送不活躍的時候。這種SCN的延時意味著在一個節點上提交的事務從另一個延時的例項上“看起來”會有點太新了。

另一方面，broadcast-on-commit方案更加資源集中一點。LGWR程式在每次commit之後更新全域性的SCN並將其廣播到所有的其他例項中。在RAC11.1中，初始化引數max_commit_propagation_delay允許資料庫管理員來修改預設的設定，這個引數在11.2中被移除。

oracle 11g RAC 的一些基本概念

RAC