不同的叢集產品都有自己的特點，RAC的特點包括如下幾點：

　　·雙機並行。RAC是一種並行模式，並不是傳統的主備模式。也就是說，RAC叢集的所有成員都可以同時接收客戶端的請求。

　　·高可用性。RAC是Oracle資料庫產品高可用性的解決方案，能夠保證在叢集中只要有一個節點存活，就能正常對外提供服務。

　　·易伸縮性。RAC可以非常容易地新增、刪除節點，以滿足系統自身的調整。

　　·低成本。能使用較低廉的伺服器來實現高可用性、高吞吐量的叢集環境，這要比通過對某臺高階伺服器增加硬體實現高可用性、高吞吐量花費的成本低很多。

　　·高吞吐量。隨著節點數的增加，整個RAC的吞吐量也在不斷增長

　　下面詳細討論這五大特點。

　　一、雙機並行

　　RAC是一種充分利用伺服器資源的高可用性實現方案，RAC的並行模式實現方式與傳統的雙機熱備實現方式截然不同，圖1-4是兩者的比較。

　　如圖1-4所示，兩個節點在傳統的雙機熱備環境中，始終有一臺機器作為備用機，只有當主節點出現問題的時候才會切換到備用機上;如果主機一直沒有出現問題，那麼備用機始終處於空閒狀態，這在資源的利用上以及成本方面都是巨大的浪費。但RAC是一種並行模式的架構，也就是說，兩個節點的叢集節點間是一種並行執行的關係，當一臺機器出現問題，請求會自動轉發到另一臺機器，沒有任何一臺機器作為備用機一直不被使用，這樣就充分利用了伺服器資源。同時，傳統的雙機熱備構架在出現問題時，常常需要數分鐘的切換時間，而RAC在出現問題時，針對存在的會話只需要數十秒的時間就可以完成失敗切換過程，對新會話的建立不會產生影響，在切換時間上也有比較大的優勢。

 ▲圖1-4 雙機熱備與RAC並行模式對比

　　二、高可用性

　　RAC是Oracle資料庫高可用性解決方案。高可用性包含兩部分的內容：首先是在這種解決方案下要確保資料不丟失，這是最基礎的也是必須要保證的;其次是確保不停機，使Oracle資料庫一直維持在正常的執行狀態，避免停機給客戶帶來的損失，這是討論最多的內容。

　　停機一般分為兩類，計劃停機和非計劃停機。所謂計劃停機是有計劃地安排節點或者系統的停機，一般在Oracle升級、系統維護或者硬體維護的情況下會出現。非計劃停機就是在非人為計劃的情況下突然停機，這種情況一般是在Oracle bug、系統故障、硬體故障或人為操作失敗的時候出現。

　　在沒有較高花費的情況下，想實現系統100%的不停機幾乎是不可能的。表1-1列出了特定百分比高可用性比率執行停機的時間，詳細記錄了每種高可用性比率每年、每月、每週可以出現最大的停機時間。

　　通常情況下，以每月停機時間來計算對應的可用性比率。根據系統的重要性情況，應該為系統設定合理的可用性比率。

　　叢集最大的優勢在於它的高可用性，通過使用RAC可以在一定程度上避免因為硬體或軟體故障引起的資料丟失和非計劃停機，並在一定程度上減少或排除計劃停機時間。這是很多客戶選擇RAC的最直接原因。

　　RAC中包含了非常多的高可用特性，主要包含如下幾點：

　　·實現節點間的負載均衡。

　　·實現失敗切換的功能。

　　·通過Service元件來控制客戶端的訪問路徑。

　　·叢集軟體能夠自動化管理各個資源，並且有定時的節點狀態檢測機制，能自動對一些失敗的程序以及心跳檢測失敗的節點進行重啟，使其重新恢復到正常的執行狀態。

　　在Oracle 11gR2版本中，Clusterware得到了改善，提供了更高的可用性。例如，大量新的基於代理的監控系統用於監控所有的資源。這些代理使用更少的資源執行更頻繁的檢查，即更快速的失敗掃描和更短的恢復時間。在Oracle監聽的例子中，平均失敗掃描時間從5分鐘減少到30秒，同時，檢查間隔從每10分鐘減少到1分鐘。另外，Clusterware的“Out-of-Place Upgrade”等特性也減少了軟體維護需要的停機時間。

　　三、易伸縮性

　　RAC為需要重新規劃的應用提供了易擴充套件性。為了在系統初始階段保持較低的成本，避免造成不必要的浪費，叢集可以按照標準硬體配置，選擇適當的伺服器資源、儲存資源來搭建資料庫環境。當系統需要更多的處理能力或者需要增加儲存時，通過新增另一臺伺服器或儲存裝置到叢集中，能夠在不停機的情況下獲得水平的擴充套件。在一個叢集中， Clusterware和RAC支援多達100個叢集節點。

　　當某個叢集的處理能力過剩，另一個叢集的處理能力不夠時，可以從處理能力過剩的叢集移動一個節點到處理能力不夠的叢集中。這樣能夠充分利用伺服器資源，節約成本。11gR2版本中推出了網格即插即用(Grid Plug and Play，GPnP)，可以實現節點的快速新增。

　　四、低成本

　　通過多臺普通的PC伺服器組成一個叢集，可以提高叢集的處理能力，這樣要比採用一臺高效能的伺服器的成本低很多。如果想提高系統的處理能力，給叢集新增節點比為高效能伺服器新增硬體要容易得多。另外，使用叢集還能動態地移除節點，更加充分地利用管理者掌握的所有伺服器資源，從伺服器整體使用上降低了伺服器的採購成本。越來越多的企業願意將叢集解決方案應用到他們的系統中，以降低成本，提高系統的可用性。

　　五、高吞吐量

　　RAC是由多臺伺服器構成的邏輯主體，比單臺數據庫伺服器能接收更多的客戶端請求。這在要求高吞吐量的系統中，能夠得到非常明顯的體現。在RAC的架構中，多個例項分佈在多個伺服器上，能同時開啟同一個資料庫，而每個例項能夠接收相等數量的客戶端請求，這樣，隨著伺服器的增加，吞吐量也在不斷地增加。

　　在以上討論的特點中，高可用性是RAC最大的特點。

　　RAC存在的問題

　　雖然RAC有非常多的優點，但由於部署一套RAC會涉及伺服器、儲存裝置、HBA卡、作業系統等多方面的技術，且從實現上要比單例項資料庫更復雜，對硬體裝置的穩定性、裝置之間以及裝置與作業系統的相容性上要求也更高，Oracle的bug也會造成RAC執行出現問題。所以，從實際的執行情況來看，RAC要比單例項的資料庫存在更多的問題，問題的原因也各不相同。RAC存在的問題主要體現在穩定性和高效能方面，下面討論這兩個問題。

　　一、穩定性

　　資料庫的穩定執行是系統穩定執行的基礎和前提，資料庫的執行依賴於作業系統、伺服器、儲存裝置等軟硬體裝置的執行情況。

　　由於各種硬體裝置、作業系統的廠商不同，有時候在相容性上會存在問題，即使同一個廠商的伺服器，由於驅動、韌體版本的不同也可能導致硬體出現問題以及與其他裝置的相容性問題。同時，由於RAC本身也存在不少bug，很多部署的RAC環境缺乏在上線前對環境的檢查和測試，導致在執行過程中出現一系列不穩定的情況，這樣高可用性並沒有得到充分的體現。

　　由此來看，穩定的硬體環境加上穩定的RAC版本，決定著RAC執行的穩定性。資料庫工程師與硬體工程師在安裝配置前大量的環境檢查、驗證，以及部署後的大量測試工作都是非常重要的。

　　二、高效能

　　高效能也是大部分從單機環境遷移到RAC環境比較頭疼的問題，RAC並不是高效能的解決方案。在目前普遍使用千兆網路的硬體環境中，很多時候系統的資料庫從原來的單機遷移至RAC環境，系統的效能反而下降。在這種情況下，資料庫管理員應該根據RAC的特點對系統調整提出合理的建議，經過合理的設計、開發，使用RAC是能夠提高系統的處理效能的。

　　以上兩個問題是需要特別注意的。另外，與硬體工程師、系統開發人員進行良好的溝通，以及對系統合理的設計是保證RAC穩定執行和高效能執行的前提。