oracle 11g RAC 的一些基本概念（四）

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中被移除。

轉載：http://blog.sina.com.cn/s/blog_5fe8502601016avf.html