Oracle RAC中最常見的錯誤觀點是因為誤解了Oracle RAC的功能與限制。以下的文章就是列舉一些關於Oracle RAC中最常見的錯誤觀點中經常出現的一些錯誤的觀點，以下就是文章的相關內容的介紹。
Oracle RAC 幾個常見的錯誤觀點
由於最終用戶習慣於獲得瞬間響應時間，Oracle為其產品提供持續可用性方面受到了前所未有的挑戰。那些在Redwood Shores(譯者注：Oracle公司總部所在地)的家伙們提供了一個重要的工具這就是什麼是RAC?簡單來說就是一套允許單個數據庫被多份Oracle程序同時訪問的軟件工具。
如果一個服務器崩潰了，事務能夠在最短的down機時間內被重定向到其他存活的服務器上的宣傳稱RAC是治愈多種疾病的良藥，而IT廠家則會對這樣的市場宣傳產生誤解，從而無法正確區別在高可用環境(HA)中使用RAC的成本和收益。
最常見的Oracle RAC錯誤觀點在於誤解了它的功能和限制。Oracle Real Application Clusters被作為綜合能力規劃戰略的一部分，但是人們並不完全明了其技術上的強項和限制。下面列舉一些關於這項技術的常見誤解。
是為了提供擴展性的盡管Oracle公司希望你買小型刀片服務器然後使用他們的網格計算方案來獲得“水平擴展”，但是實際上這並不是多數用戶使用RAC的方法。注意：RAC只是在超大型IT部門需要超過單個服務器提供極限的更多馬力時的一種正統擴展方法。
作為Oracle最佳實踐，要通過“垂直擴展”先進行單個服務器的擴容，先向上擴展再向外擴展。只有在你使單個服務器容量飽和之後再考慮“scale out”到多個服務器上。今天，單個服務器的內存和CPU馬力比起前幾年來說有了突飛猛進，因此比起往RAC環境中添加一個新服務器而言，增加單個機器的資源更加簡單。
在真實環境中，單個服務器能夠處理每秒上千次的事務。只有世界上最大的那些Oracle數據庫需要擴展到使用RAC。
Oracle RAC是獨立的高可用解決方案
記住RAC只能保護你免於實例失效，這僅僅是眾多可能引起非計劃性中斷的原因之一。為了真正的持續可用性，我們還必須部署多重鏡像磁盤和冗余網絡組件。
為了每個RAC節點的可用性，需要多個冗余的主機總線適配器，多個網卡以及多個電源。就算只是在數據庫實例產生了failover，你也需要提供軟件以允許多個主機總線適配器自動failover，並且提供單個組件失效通知。
就像我們已經提到的，RAC系統需要一個cluster interconnect來提供內存對內存(RAM-to-RAM)的數據塊傳輸。Interconnect必須非常快速，必須有高帶寬和低延遲。Interconnects包括
Cache fusion上的瓶頸也是為什麼RAC擴展或者說水平擴展有問題的另外一個原因。如果你的cluster interconnect無法處理這樣的流量，那麼額外的服務器將會降低整個系統的性能而不是提升它。解決這個問題的唯一辦法就是改造應用以適應RAC，或者采購更快的存儲比如說固態硬盤。
保證了快速響應時間事務響應時間總是重要的，但是它對於RAC數據庫來說尤為重要。這是因為在連接階段為了探測是否一個RAC節點或者機器已經失效而消耗了等待時間，因此你必須保證新事務要小於1秒時間這樣才能保證2秒的failover時間。
Oracle RAC不需要災難恢復組件除了在少數案例中使用了DWDM技術(也就是dark fiber)，你仍然需要創建一份災難恢復解決方案。因為RAC節點通常只間隔數英裡，像飓風這樣的自然災害還是能夠引起全局中斷。因此RAC最佳實踐中還是要包含一份地理上的快速失效接管解決方案，比如Data Guard或者更好一些，多路流復制。
