標籤：des blog http 使用 io 檔案 資料 ar
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
