這一部分我們在RAC上應用的高可用設計的層面上，討論一些Oracle數據庫的特性。我們同時也會指出，什麼地方可用性會被限制，比如打補丁和重要的數據庫升級。然後我們將視線轉移到站點間的可用性，討論Data Guard(災備)和Oracle Streams(信息共享與複製)。RAC解決方案不是孤立的，很多組件扮演一個角色、很多技術被利用來搭建一個健壯的、高可用的、可擴展的應用。
可用性
很多用戶選擇RAC解決方案，因爲他們需要他們的應用對客戶持續可用，且可以容忍一些類型的故障而不會中斷服務。在這個應用多層、面向網絡的時代，可用性和應用的可擴展性事保證用戶基礎的關鍵。調查發現，如果用戶在瀏覽器訪問一個web頁面，如果在大約十秒鐘以內不能完全出現結果，那麼他們會很煩躁，常常會離開很少還會回來。
會損害系統的可用性的中斷從根本上分爲兩類：計劃和非計劃。Oracle技術提供了大量互補的技術，可以避免幾乎所有類型的中斷。下面兩個表分別列出非計劃中斷的挽救措施和避免中斷的技術。
![]()
![]()
![]()
節點數的決策
很多RAC系統都只有兩個節點。你可以常常在英國的Oracle用戶會議的舉手投票中得到這樣的結果。這樣的系統常常用在類似active/passive集羣中，RAC完全爲了高可用而部署。
適當的節點數的討論不應該侷限在在線生產系統。在用戶適應RAC以前，他們很可能在類似展示和質量保證的生產前環境中考慮過節點數量，也可以用作容災方案。由於很多原因，有一個與生產環境一樣的生產前的環境是很有益處的，否則你可能會在代碼發佈以後經歷不愉快的體驗。你可以在一個與生產環境完全一樣的拷貝中進行測試——如果你的數據與生產環境不同步；所有的測試都有可能出錯。一個非生產的RAC集羣是必要的，用來在生產庫裏應用補丁前先在非生產庫裏測試，以避免非計劃中斷或Oracle程序文件的損壞。
如果沒有多餘的硬件或預算來創建一個用來測試RAC系統，你可以在一個服務器上創建一個虛擬的RAC系統。Oracle VM是一個免費的虛擬機管理軟件。
災難恢復(DR)站點的性能應該與生產站點相同；當發生危機需要啓用DR站點時的最後一件事，是確保DR站點能承載工作量。將老的生產環境回收來作爲DR是不推薦的。
雙節點RAC集羣
兩節點的RAC有一些優勢：首先，購買許可的成本比較低；第二，只有兩個節點可以使全局緩存轉移得到簡化，因爲不會出現三向的通訊。標準版RAC的許可條件看起來不允許超過2個裝備了新型處理器的節點，因此你的拓撲不如企業版的靈活。
當設計和實施這樣的安裝，每個單獨的節點需要在發生節點故障時承擔所有的負載。或者在這樣的情況下，通知用戶只進行必要的操作來使工作量降低。單獨的RAC節點的處理能力可能會隨着時間而降低，那時候會有更大的問題，因此這些安裝必須能承受大於全部工作量的負載。
Oracle RAC One Node
在Oracle 11.2中，引入了一種介於RAC和active/passive中間的混合RAC，它叫做RAC One Node。當你需要擴展到完全的RAC時，這種轉換將比較簡單。RAC One Node的主要目的之一是允許計劃停機，例如，運行中的數據庫實例可以使用omotion工具移動到另一臺主機上而對應用沒什麼影響，然後可以在原先運行實例的主機中進行維護操作。與RAC系統不同，它只有一個實例來爲用戶連接服務；不過，它還是需要以RAC數據庫的方式創建。
這個實例註冊在Oracle Grid Infrastructure、元數據倉庫和集羣高可用框架中。通過這種方法，RDBMS實例可以從Grid Infrastructure提供的高可用選項中獲益，也就是故障檢測和保護、在線滾動打補丁和在線滾動升級。
RAC One Node發佈的第一個版本是在11.2.0.1，只能用在Linux系統中。它不支持Data Guard，在默認的安裝中也不可用。對RAC One Node感興趣的用戶必須下載My Oracle Support補丁9004119。其他平臺的管理員想使用的話需要等待第一個補丁集的發佈。用戶指南還提示RAC One Node將不支持第三方集羣軟件，比如Veritas Storage Foundation for RAC或者HP Serviceguard。一旦RAC數據庫在一個節點上創建，一些工具將作爲上面提到的補丁的一部分安裝，允許用戶將系統轉換成RAC
One Node數據庫。這個轉換通過raconeinit命令來進行，當它執行完畢後，你會發現數據庫實例被重命名爲instanceName_1。
就像上面提到的，一個新的工具叫omotion允許用戶將一個RAC One Node實例轉移到集羣中的另一個節點上。當需要對節點做一個計劃維護，或者你的集羣節點用完了所有資源，容納不下數據庫的時候，移動實例會很有用途。爲了減輕應用上對用戶的影響，需要使用TAF或FCF。如果不使用的話，正在執行的事務會在某個用戶可定義窗口中完成；然後，接下來用戶連接將會被斷開，並出現ORA-3113"End of line on communication channel"錯誤。這個錯誤是由寬限期後開始的數據庫實例的關閉導致的。
如果需要將一個RAC One Node轉變爲"full" RAC，另一個工具racone2rac可以用來簡化這個過程。只需要從一個文本菜單中選擇你的RAC One Node數據庫，然後讓這個工具將其轉換爲RAC數據庫。轉換的結果看起來與使用policy-managed數據庫的結果類似。policy-managed數據庫是11.2中引入的新特性，標誌了傳統RAC數據庫的一個轉變，以前數據庫管理員需要負責管理RAC數據庫的所有方面，比如初始化參數、在線redo線程和其他結構上的改變。通過policy-managed數據庫，DBA只需要定義數據庫節點的數量，Oracle會接管剩下的工作(增加/刪除節點)。所有需要而當前沒有的組件都會自動創建。
多節點RAC系統
當單個節點發生故障時，多節點的系統比雙節點集羣更容易支撐所有的工作量。一個正確設計的RAC系統應該有足夠的冗餘來保證應用可以繼續運行，產生儘量小的中斷。因此很多企業採用了超過2個節點的RAC。在這種情況下，設計一個n節點的集羣時，這個集羣應該在只有n-1節點工作時支持全部的工作量。這意味着集羣中有一個節點可以作爲冗餘，這個冗餘的節點也不需要處於閒置狀態。比如，它可以用來做備份和報告；唯一的要求是，它能在短時間內爲集羣提供它的處理能力。
從Oracle 10.1開始，當確定當前集羣的節點數不足以支持工作量時，可以在線添加節點到集羣中。在Oracle 11.2中，引入了網格即插即用和策略管理的數據庫使這個過程得到了改進和簡化。
在線維護和打補丁
不管一個新的系統在上線前經過了多麼仔細的測試，它遲早需要打補丁。這有多個原因，通常主要原因如下：一個內部錯誤導致應用不可用；當前使用的版本馬上要不被支持。例如，Oracle在2010年不再主要支持10g r2（但Oracle將服務免費延長一年），這可能會是將數據庫升級到下一個版本的原因；一個關鍵的安全補丁需要應用；合同要求履行預定的維護工作。
打補丁會對可用性產生影響，雖然Oracle通過在線打補丁和滾動補丁應用機制改進了這種狀況。Oracle中補丁應用的主要工具是opatch。但是，關鍵的版本審計不能通過opatch來執行，你需要使用OUI來來達到這個目的。
（有一點很重要，在高可用系統中，不要爲了打補丁而打補丁。）
所有的補丁應用都是有風險的，不管你事先做了多少測試。幾乎所有的DBA都可以講述一個因爲應用補丁導致的錯誤。打補丁同時意味着在一個節點中修改二進制文件時，需要提供這個節點的停機時間。
在Oracle數據庫領域裏，有一些不同種類的補丁，下表做一個介紹：
使用opatch爲RAC打補丁
過去，系統打補丁大多都意味着要停機。但是現在，opatch支持集羣的滾動升級，最小化服務可用性的中斷。在嘗試打任何補丁之前，確定Oracle Inventory中包含了集羣中所有節點和它們補丁級別的元數據沒有損壞是很重要的。全局目錄在所有補丁操作期間都被維護，它列出了RAC集羣中的可用的Oracle目錄。運行opatch工具帶lsinventory參數來確定目錄沒有損壞，比如 $ORACLE_HOME/OPatch/opatch
lsinventory
你會在接近輸出底部的地方發現一些重要信息；opatch工具可以正確找出RAC的節點，同樣可以正確檢測到命令運行在哪個本地節點上。如果opatch報告的信息是錯誤的，不要繼續打補丁，因爲opatch不能把補丁信息正確註冊到全局目錄中。
Opatch操作模式
OPatch在RAC中可以在四種不同的模式下操作：All node patch；Rolling patch；Minimum Downtime patch；Local patch
All Node Patch模式
Opatch對待集羣就像在單實例中一樣，在數據庫停止的時候對所有的節點打補丁。這個補丁模式對可用性的影響最大，只能在一個約定的停機窗口中執行。否則這個模式不真正適用於RAC系統。
Rolling Patch模式
集羣中的所有節點都打上補丁，但一次只有一個，以避免停機。第一個節點將被停下來打補丁，打完補丁以後，它會重新啓動。OPatch會詢問你是否要繼續下一個節點，直到所有節點都打完補丁。由於至少會有一個節點保持在線爲用戶提供服務，因此沒有停機。
不幸運的是，不是所有的補丁都支持這種模式。你可以使用opatch的query選項來確定是否支持，例如：
[grid@london1 PSU1]$ $ORACLE_HOME/OPatch/opatch query \
> -is_rolling_patch 9343627/
Invoking OPatch 11.2.0.1.2
Oracle Interim Patch Installer version 11.2.0.1.2
Copyright (c) 2010, Oracle Corporation. All rights reserved.
Oracle Home : /u01/app/grid/product/11.2.0/crs
Central Inventory : /u01/app/oraInventory
from : /etc/oraInst.loc
OPatch version : 11.2.0.1.2
OUI version : 11.2.0.1.0
OUI location : /u01/app/grid/product/11.2.0/crs/oui
Log file location : /u01/.../opatch/opatch2010-06-14_16-41-58PM.log
Patch history file: /u01/.../cfgtoollogs/opatch/opatch_history.txt
---------------------------------------------------------------------------
Patch is a rolling patch: true
OPatch succeeded.
Minimum Downtime Patch模式
在這種策略下，你將集羣的節點分成兩部分。打補丁的時候，第一個節點集會關閉實例並開始打補丁，當打完補丁時，第二個節點集將關閉。這時候第一批打補丁的節點已經啓動了。當第二部分的節點也打完補丁，這些家電將重新啓動，整個集羣都已經應用完補丁了。
Local Patch模式
最後，集羣中的單個節點可以在opatch中指定-local來打補丁。可以使用這種方法來實現與rolling patch類似的功能。最後，你要確認補丁信息在每個節點的Oracle inventory中正確記錄了。
使用哪一種模式來打補丁取決於可用性需求和用戶或業務的需要。Minimum downtime模式和rolling patching是類似的，使用讓集羣部分可用的方式來進行。一些業務可以擁有周末的停機時間，因此他們可以選擇all-node補丁方式，更節省時間和資源。
RAC中的實例恢復
另一個影響RAC系統可用性的角色就是實例恢復。先前提到過，實例故障不會像單實例Oracle中一樣導致應用的完全中斷，立即變得不可用，用戶也會感覺到這個故障。在單實例情況下，構建了SGA的內存結構會馬上消失，並且需要在實例再次啓動是重新構建。如果這種情況發生，系統監控進程(SMON)必須執行實例恢復來使數據庫回到一致狀態，並對用戶可用。不幸運的是，這會花些時間。
RAC中的實例恢復和單實例情況中有很大的不同，並且它不會導致中斷。集羣中的另一個實例將會檢測到一個實例的故障，一旦檢測到，後臺進程會在集羣內remaster故障的資源，用戶會感覺到短暫的停頓。系統不可用或局部不可用的時間窗口取決於系統的活躍程度、故障實例所master的塊的數量、和故障節點持有的(比如隊列)全局資源數。
任意一個其他實例將代替故障的實例管理實例恢復。有兩個工作流程需要完成：
隊列Remastering：全局隊列服務監控需要恢復諸如隊列(主要有TX何TM事務和表級修改的隊列)和buffer cache中的緩存資源之類的全局資源。
數據庫恢復：SMON進程執行數據庫恢復，就像它在單實例情況下做的一樣。
這些操作中有一些是可以並行執行的。
Enqueue Remastering
實例恢復的第一步就是remaster全局隊列，由全局隊列服務(GES)來執行。你可以把隊列看做全局鎖，實例崩潰會導致全局資源目錄中維護的一些隊列的元數據丟失，它必須由同時工作的存活的實例來恢復。LMON全局隊列服務監控進程負責這項工作。
所有的集羣節點在它們的SGA中共同維護全局資源目錄(GRD)。需要訪問資源的集羣操作需要同步，而這正是GRD要乾的。GRD由全局緩存服務進程和全局隊列服務進程維護，它們負責管理共享SGA中的塊和全局鎖。集羣中的每個資源都由一個指定的實例來master，其它的所有實例都知道一個資源的resource master是哪一個實例。
全局隊列的恢復時間與系統工作量、故障實例數和掛起的工作有關。在一個繁忙的系統中，你往往會發現TM和TX隊列(表/分區修改隊列和事務隊列)的remaster花費的時間最長。在過去(那時還是Oracle Parallel Server)，用戶嘗試將初始化參數dml_locks設置爲0，你偶爾還能在英特網上看到這個建議，但是要小心！當這個設置起作用並禁用了隊列，會remaster一個快速進程，同樣會強制添加一些限制，使得這個方法不適用於現在的環境。特別是，將dml_locks設爲0會導致下面的限制：
- 你不能使用drop table或create index表達式
- 顯式的lock表達式將不被允許。比如，你不能使用LOCK TABLE表達式
- 你不能在任何實例上使用企業管理器。
不值得花時間來做這個參數的試驗。像先前提到過的一樣，RAC實例恢復會對你的應用產生影響。所以，你要在將其投入生產之前徹底地測試你的應用在實例故障時的情況。
實例恢復的第二步是remaster全局緩存資源，它們是buffer cache中的塊。全局緩存服務進程GCS，負責這個工作。爲了提高這個過程的速度，只有那些失去了master的資源會被remaster。這種方法是從以前的版本中演變過來的，在以前，所有的資源會被remaster，顯然，早先的方法會花更多的時間來完成這個過程。當資源正在remaster的時候，LMS全局緩存服務進程不會處理額外的訪問buffer cache中塊的請求。那些足夠幸運獲得處理、且不需要請求更多資源(塊)的會話，將會繼續工作。其它的所有會話必須等待到市裏恢復過程結束。
數據庫恢復
當全局緩存資源(數據庫塊)正在remaster時，服務器監控進程啓動恢復集的建立。恢復集(recovery set)是需要恢復的塊的集合，SMON服務器監控進程需要將所有線程的在線redo日誌進行合併，來完成這個恢復集。
SMON同樣執行實例恢復的下一步步驟。前面由SMON決定的需要用於恢復的資源，恢復集，在它們等待恢復的時候要預防其它實例來訪問它們。
在這個步驟中，全局資源目錄會被解凍。全局資源已經被remaster(分佈在存活的集羣節點中)，恢復需要的所有數據塊被鎖住，使得SMON可以對它們應用redo。現在可以準備繼續了，buffer cache中的所有其它塊都可以讓用戶訪問，系統處於部分可用的狀態。和單實例Oracle中一樣，一些塊髒了，因爲它們的對應的事務還沒有結束。這些塊上的更改應該通過應用undo信息來回退。當恢復集中的所有塊都被恢復，且相應的資源被釋放後，系統將重新變得完全可用。
這個漫長的討論闡述了爲什麼你可能想讓實例恢復過程越短越好的原因。首先，也是最主要的，你更願意保持用戶連接和應用繼續工作。不幸運的是，RAC中並沒有像單實例Oracle中用來在數據庫崩潰後控制實例啓動時間的參數fast_start_mttr_target。這個參數取代了log_checkpoint_interval、log_checkpoint_timeout和fast_start_io_target。設置fast_start_mttr_target允許Oracle填充V$INSTANCE_RECOVERY視圖，可以給管理員一個關於實例恢復大概時間的一個參考。
在恢復的場景中，你可以設置recovery_parallelism爲一個非默認的值來增加恢復過程中的從屬進程來加快恢復速度(需要parallel_max_servers>0)。
Oracle 10g引入了一個下劃線參數叫_fast_start_instance_recovery_target，它能讓你影響執行實例恢復需要的時間。和任何一個下劃線參數一樣，你需要先從Oracle support中瞭解設置這個參數是否會造成什麼不良影響。_fast_start_instance_recovery_target參數控制實例恢復開始到前滾完畢間的最大時間，換句話說，它控制了系統不可用時的時間間隔。
摘自 Pro Database 11g RAC on Linux
