1. RAC 介紹

Oracle Real Application Cluster (簡稱 RAC) 是一種資料庫的叢集 (Cluster) 架構，最早在 Oracle 8i 稱作 Parallel Server ，從 Oracle 9i 開始有了 RAC 這個名稱。早在 Oracle 9i 當時， Oracle 還沒有屬於自己的 Cluster Ware ，搭建 RAC 需要配合第三方的 Cluster 軟體來輔助，例如 Sun Cluster 、 IBM 的 HACMP 、 HP 的 Service Guard 、 Veritas Cluster (VCS) …等，到了 Oracle 10g 以後便推出了屬於 Oracle 自己的 Cluster Ware 並配合 ASM 的架構下來搭建 RAC ，從此以後就不再需要第三方的 Cluster 軟體了，到了 Oracle 11g 之後， RAC 改稱為 Grid Infrastructure 直至今日的版本，不論是早期的 Parallel Server 或者是 RAC 、 Grid Infrastructure ，指的都是 Oracle Cluster 架構。

所謂的 Cluster ，指的就是將多台 Server 組成一個 Group ，這個 Group 底下所有的成員用來支撐同一種服務，如果是只有一台 Server ，那麼當這台 Server 有問題的時候，運行在上面的服務也就不能使用；而 Cluster 的好處在於有多台 Server 來支撐服務，所以當其中有一台 Server 發生問題時，這個 Cluster 群組裡還有其它的 Server 可以用來運行服務，此時不會因為單一 Server 發生狀況而導致服務中斷，而多台 Server 如何能夠組成一個 Group ，這時候就是需要叢集軟體 (Cluster Ware) 來達成。

Cluster 在種類上可以分為 Sharing Everything 與 Sharing Nothing 兩大類， Sharing Everything 表示所有的 Server 必須共享一個存儲，這個 Storage 的空間必須共同給所有的 Server 來使用；而 Sharing Nothing 表示每台 Server 都有屬於自己的存儲空間，並且每台 Server 都擁有這項服務的一部分資料。對於 RAC 來說，使用的是 Sharing Everything 架構，所以搭建 RAC 前的其中一項任務，就是要設定好 Shared Storage 來給所有 Server 來使用。

Cluster 架構在服務的提供上，多數的 Cluster 只能做到 Active – Standby 架構，也就是平時只有 Cluster 群組中的一個 Server 來提供服務，如果這台 Server 發生問題的話，再由另一台 Server 接手繼續提供服務:

 

而 Oracle RAC 是少數能夠真正做到 Active – Active 服務的架構，並且不需要額外的 Management Server 來避免叢集發生腦裂 (Split-brain) 的情況。 Active – Active 架構是在叢集中所有的 Server 都能夠用來提供服務，當中如果有 Server 發生問題的話，其餘的 Server 仍然是可以馬上接手提供服務:

有了 Cluster 的概念之後，那麼就可以進一步理解 RAC Database 的構成，傳統單機資料庫來說，是一個 Instance 對應一個 Database :

而 RAC Database ，是多台 Server ，每個 Server 都有一個 Instance ，共同來支撐同一個資料庫:

RAC Database 的優點是，由於有多個 Instance 來支撐這個資料庫，因此不會因為有某台 Server 或某個 Instance 發生問題導致資料庫無法運行，只要其中有一個 Instance 還活著，那麼資料庫就可以正常的運行；其次是可以把服務分散在不同個 Instance 上執行，傳統單一 Server 的狀況下，如果 Server 的負載過重，那麼只能想辦法來增加硬體資源，而 RAC 的好處是有多個 Instance ，把服務分散在這些 Instance 上執行也就等於分散了每台 Server 的負載，萬一所有的 Server 都已經滿載，那麼 RAC 還可以添加 Server 到這一個叢集當中，而這個添加的過程不需要停止資料庫服務。

目前現實環境來說，都希望提供的服務可以不中斷， RAC 就提供了非常好的 HA (High Availability)  機制，為多數企業建置資料庫時的優先選擇，但這邊要注意的是， RAC 的優點在於它的高可用性機制，資料庫的效能不會因為把它轉換為 RAC 然後就會提升，如果使用不好的話很有可能因為 Global Cache 的因素導致效能下降，雖然 RAC 本身提供了 Load Balance 機制，但是建議在 RAC 的使用上，把服務區分並且運行在不同的 Instance 上會是比較好的做法，例如一個 RAC 資料庫 ORCL 提供了 A,B 兩種服務，那麼規劃上把 A 服務運行在 Instance 1 (ORCL1) 、 B 服務運行在 Instance 2 (ORCL2) ，這種使用方式會是比較好的選擇。