一 集群環境下的一些特殊問題
1.1 並發控制
在集群環境中， 關鍵數據通常是共享存放的，比如放在共享磁盤上。 而各個節點的對數據有相同的訪問權限， 這時就必須有某種機制能夠控制節點對數據的訪問。 Oracle RAC 是利用DLM(Distribute Lock Management) 機制來進行多個實例間的並發控制。
1.2 健忘症(Amnesia)
集群環境配置文件不是集中存放的，而是每個節點都有一個本地副本，在集群正常運行時，用戶可以在任何節點更改集群的配置，並且這種更改會自動同步到其他節點。
有一種特殊情況： 節點A 正常關閉， 在節點B上修改配置， 關閉結點A，啟動結點B。 這種情況下，修改的配置文件是丟失的， 就是所謂的健忘症。
1.3 腦裂(Split Brain)
在集群中，節點間通過某種機制(心跳)了解彼此的健康狀態，以確保各節點協調工作。 假設只有"心跳"出現問題， 各個節點還在正常運行， 這時，每個節點都認為其他的節點宕機了， 自己是整個集群環境中的"唯一建在者"，自己應該獲得整個集群的"控制權"。 在集群環境中，存儲設備都是共享的， 這就意味著數據災難， 這種情況就是"腦裂"
解決這個問題的通常辦法是使用投票算法(Quorum Algorithm). 它的算法機理如下：
集群中各個節點需要心跳機制來通報彼此的"健康狀態"，假設每收到一個節點的"通報"代表一票。對於三個節點的集群，正常運行時，每個節點都會有3票。 當結點A心跳出現故障但節點A還在運行，這時整個集群就會分裂成2個小的partition。 節點A是一個，剩下的2個是一個。 這是必須剔除一個partition才能保障集群的健康運行。
對於有3個節點的集群， A 心跳出現問題後， B 和 C 是一個partion，有2票， A只有1票。 按照投票算法， B 和C 組成的集群獲得控制權， A 被剔除。
如果只有2個節點，投票算法就失效了。 因為每個節點上都只有1票。 這時就需要引入第三個設備：Quorum Device. Quorum Device 通常采用餓是共享磁盤，這個磁盤也叫作Quorum disk。 這個Quorum Disk 也代表一票。 當2個結點的心跳出現問題時， 2個節點同時去爭取Quorum Disk 這一票， 最早到達的請求被最先滿足。 故最先獲得Quorum Disk的節點就獲得2票。另一個節點就會被剔除。
1.4 IO 隔離(Fencing)
當集群系統出現"腦裂"問題的時候，我們可以通過"投票算法"來解決誰獲得集群控制權的問題。 但是這樣是不夠的，我們還必須保證被趕出去的結點不能操作共享數據。 這就是IO Fencing 要解決的問題。
IO Fencing實現有硬件和軟件2種方式：
軟件方式：對於支持SCSI Reserve/Release 命令的存儲設備， 可以用SG命令來實現。 正常的節點使用SCSI Reserve命令"鎖住"存儲設備， 故障節點發現存儲設備被鎖住後，就知道自己被趕出了集群，也就是說自己出現了異常情況， 就要自己進行重啟，以恢復到正常狀態。 這個機制也叫作 Sicide(自殺). Sun 和Veritas 使用的就是這種機制。
硬件方式：STONITH(Shoot The Other Node in the Head)， 這種方式直接操作電源開關，當一個節點發生故障時，另一個節點如果能偵測到，就會通過串口發出命令，控制故障節點的電源開關，通過暫時斷電，而又上電的方式使故障節點被重啟動， 這種方式需要硬件支持。
二 RAC 集群
2.1 Clusterware
在單機環境下，Oracle是運行在OS Kernel 之上的。 OS Kernel負責管理硬件設備，並提供硬件訪問接口。 Oracle 不會直接操作硬件，而是有OS Kernel代替它來完成對硬件的調用請求。
在集群環境下， 存儲設備是共享的。OS Kernel 的設計都是針對單機的，只能控制單機上多個進程間的訪問。 如果還依賴OS Kernel的服務，就無法保證多個主機間的協調工作。 這時就需要引入額外的控制機制，在RAC中，這個機制就是位於Oracle 和 OS Kernel 之間的Clusterware，它會在OS Kernel之前截獲請求，然後和其他結點上的Clusterware協商，最終完成上層的請求。
在Oracle 10G之前，RAC 所需要的集群件依賴與硬件廠商，比如SUN,HP,Veritas. 從Oracle 10.1版本中，Oracle 推出了自己的集群產品. Cluster Ready Service(CRS),從此RAC 不在依賴與任何廠商的集群軟件。 在Oracle 10.2版本中，這個產品改名為：Oracle Clusterware。
所以我們可以看出， 在整個RAC 集群中，實際上有2個集群環境的存在，一個是由Clusterware 軟件組成的集群，另一個是由Database 組成的集群。
2.2 Clusterware 組成
Oracle Cluster 是一個單獨的安裝包，安裝後，在每個結點上的Oracle Clusterware 會自動啟動。 Oracle Clusterware的運行環境由2個磁盤文件(OCR,Voting Disk)，若干進程和網絡元素組成。
2.2.1 磁盤文件:
Clusterware 在運行期間需要兩個文件：OCR和Voting Disk. 這2個文件必須存放在共享存儲上。 OCR 用於解決健忘問題，Voting Disk 用於解決健忘問題。 Oracle 建議使用裸設備來存放這2個文件，每個文件創建一個裸設備，每個裸設備分配100M左右的空間就夠了。
2.2.1.1 OCR
健忘問題是由於每個節點都有配置信息的拷貝，修改節點的配置信息不同步引起的。 Oracle 采用的解決方法就是把這個配置文件放在共享的存儲上， 這個文件就是OCR Disk。
OCR 中保存整個集群的配置信息，配置信息以"Key-Value" 的形式保存其中。 在Oracle 10g以前， 這個文件叫作Server Manageability Repository(SRVM). 在Oracle 10g， 這部分內容被重新設計，並重名為OCR.在Oracle Clusterware 安裝的過程中， 安裝程序會提示用戶指定OCR位置。並且用戶指定的這個位置會被記錄在/etc/oracle/ocr.Loc(Linux System) 或者/var/opt/oracle/ocr.Loc(Solaris System)文件中。 而在Oracle 9i RAC中，對等的是srvConfig.Loc文件。 Oracle Clusterware在啟動時會根據這裡面的內容從指定位置讀入OCR 內容。
1). OCR key
整個OCR 的信息是樹形結構，有3個大分支。分別是SYSTEM,DATABASE 和CRS。每個分支下面又有許多小分支。這些記錄的信息只能由root用戶修改。
2) OCR process
Oracle Clusterware 在OCR中存放集群配置信息，故OCR 的內容非常的重要，所有對OCR的操作必須確保OCR 內容完整性，所以在ORACLE Clusterware運行過程中，並不是所有結點都能操作OCR Disk.
在每個節點的內存中都有一份OCR內容的拷貝，這份拷貝叫作OCR Cache。 每個結點都有一個OCR Process 來讀寫OCR Cache，但只有一個節點的OCR process能讀寫OCR Disk中的內容，這個節點叫作OCR Master結點。 這個節點的OCR process 負責更新本地和其他結點的OCR Cache內容。
所有需要OCR 內容的其他進程，比如OCSSD,EVM等都叫作Client Process， 這些進程不會直接訪問OCR Cache，而是像OCR Process發送請求，借助OCR Process獲得內容，如果想要修改OCR 內容，也要由該節點的OCR Process像Master node 的OCR process 提交申請，由Master OCR Process完成物理讀寫，並同步所有節點OCR Cache中的內容。
2.2.1.2 Voting Disk
Voting Disk 這個文件主要用於記錄節點成員狀態，在出現腦裂時，決定那個Partion獲得控制權，其他的Partion必須從集群中剔除。在安裝Clusterware時也會提示指定這個位置。 安裝完成後可以通過如下命令來查看Voting Disk位置。
$Crsctl query css votedisk
2.2.2 Clusterware 後台進程
Clusterware 由若干進程組成，其中最重要的3個是：CRSD,CSSD,EVMD. 在安裝clusterware的最後階段，會要求在每個節點執行root.sh 腳本， 這個腳本會在/etc/inittab 文件的最後把這3個進程加入啟動項，這樣以後每次系統啟動時，Clusterware 也會自動啟動，其中EVMD和CRSD 兩個進程如果出現異常，則系統會自動重啟這兩個進程，如果是CSSD 進程異常，系統會立即重啟。
1). OCSSD
OCSSD 這個進程是Clusterware最關鍵的進程，如果這個進程出現異常，會導致系統重啟，這個進程提供CSS(Cluster Synchronization Service)服務。 CSS 服務通過多種心跳機制實時監控集群狀態，提供腦裂保護等基礎集群服務功能。
CSS 服務有2種心跳機制： 一種是通過私有網絡的Network Heartbeat，另一種是通過Voting Disk的Disk Heartbeat.
這2種心跳都有最大延時，對於Disk Heartbeat， 這個延時叫作IOT (I/O Timeout);對於Network Heartbeat, 這個延時叫MC(Misscount)。 這2個參數都以秒為單位，缺省時IOT大於MC，在默認情況下，這2個參數是Oracle 自動判定的，並且不建議調整。可以通過如下命令來查看參數值：
$crsctl get css disktimeout
$crsctl get css misscount
注：除了Clusterware 需要這個進程，在單節點環境中如果使用了ASM，也需要這個進程；這個進程用於支持ASM Instance 和RDBMS Instance之間的通信。 如果在使用了ASM的節點上安裝RAC，會遇到一個問題：RAC節點要求只有一個OCSSD進程，並且應該是運行$CRS_HOME目錄下的，這時就需要先停止ASM，並通過$ORACLE_HOME/bin/localcfig.Sh delete 刪除之前的inittab 條目。 之前安裝ASM時，也使用這個腳本來啟動OCSSD： $ORACLE_HOME/bin/localconfig.Sh add.
2). CRSD
CRSD是實現"高可用性(HA)"的主要進程，它提供的服務叫作CRS(Cluster Ready Service) 服務。
Oracle Clusterware是位於集群層的組件，它要為應用層資源(CRS Resource) 提供"高可用性服務"，所以， Oracle Clusterware 必須監控這些資源，並在這些資源運行異常時進行干預，包括關閉，重啟進程或者轉移服務。CRSD進程提供的就是這些服務。
所有需要 高可用性 的組件，都會在安裝配置的時候，以CRS Resource的形式登記到OCR中，而CRSD 進程就是根據OCR中的內容，決定監控哪些進程，如何監控，出現問題時又如何解決。也就是說，CRSD 進程負責監控CRS Resource 的運行狀態，並要啟動，停止，監控，Failover這些資源。 默認情況下，CRS 會自動嘗試重啟資源5次，如果還是失敗，則放棄嘗試。
CRS Resource 包括GSD(Global Serveice Daemon),ONS(Oracle Notification Service),VIP, Database, Instance 和 Service. 這些資源被分成2類：
GSD，ONS,VIP 和 Listener 屬於Noteapps類
Database，Instance 和Service 屬於 Database-Related Resource 類。
我們可以這樣理解： Nodeapps 就是說每個節點只需要一個就夠了，比如每個節點只有一個Listener，而Database-Related Resource 就是說這些資源和數據庫有關，不受節點的限制，比如一個節點可以有多個實例，每個實例可以有多個Service。
GSD，ONS,VIP 這3個服務是在安裝Clusterware的最後，執行VIPCA 時創建並登記到OCR中的。 而Database， Listener， Instance 和Service 是在各自的配置過程中自動或者手動登記到OCR中的。
3). EVMD
EVMD 這個進程負責發布CRS 產生的各種事件(Event). 這些Event可以通過2種方式發布給客戶：ONS 和 Callout Script. 用戶可以自定義回調腳本，放在特定的目錄下，這樣當有某些事件發生時，EVMD會自動掃描該目錄，並調用用戶的腳本，這種調用是通過racgevt進程來完成的。
EVMD 進程除了復雜發布事件之外，它還是CRSD 和CSSD 兩個進程之間的橋梁。 CRS 和CSS 兩個服務之前的通信就是通過EVMD 進程完成的。
4). RACGIMON
RACGIMON 這個進程負責檢查數據庫健康狀態，負責Service的啟動，停止，故障轉移(Failover)。 這個進程會建立到數據庫的持久連接，定期檢查SGA中的特定信息，該信息由PMON 進程定時更新。
5). OPROCD
OPROCD 這個進程也叫作 Process Monitor Daemon. 如果在非Linux 平台上，並且沒有使用第三方的集群軟件時，就會看到這個進程。 這個進程用來檢查節點的Processor Hang(CPU 掛起), 如果調度時間超過1.5秒， 就會認為CPU 工作異常，會重啟節點。 也就是說這個進程提供 "IO 隔離" 的功能。 從其在Windows 平台上的服務名： OraFnceService 也可以看出它的功能。 而在Linux 平台上， 是利用Hangcheck-timer 模塊來實現"IO 隔離"的。
2.3 VIP 原理和特點
Oracle 的TAF 就是建立在VIP 技術之上的。 IP 和VIP 區別在與： IP 是利用TCP層超時， VIP 利用的是應用層的立即響應。VIP 它是浮動的IP. 當一個節點出現問題時會自動的轉到另一個節點上。
假設有一個2個節點的RAC，正常運行時每個節點上都有一個VIP。 VIP1 和VIP2. 當節點2發生故障，比如異常關系。 RAC 會做如下操作：
1). CRS 在檢測到rac2節點異常後，會觸發Clusterware 重構，最後把rac2節點剔除集群，由節點1組成新的集群。
2). RAC的Failover 機制會把節點2的VIP轉移到節點1上，這時節點1的PUBLIC 網卡上就有3個IP 地址： VIP1,VIP2, PUBLIC IP1.
3). 用戶對VIP2的連接請求會被IP層路由轉到節點1
4). 因為在節點1上有VIP2的地址，所有數據包會順利通過路由層，網絡層，傳輸層。
5). 但是，節點1上只監聽VIP1和public IP1的兩個IP地址。並沒有監聽VIP2，故應用層沒有對應的程序接收這個數據包，這個錯誤立即被捕獲。
6). 客戶段能夠立即接收到這個錯誤，然後客戶段會重新發起向VIP1的連接請求。
VIP 特點：
1). VIP 是通過VIPCA腳本創建的
2). VIP 作為Nodeapps類型的CRS Resource 注冊到OCR中，並由CRS 維護狀態。
3). VIP 會綁定到節點的public 網卡上，故public 網卡有2個地址。
4). 當某個節點發生故障時，CRS 會把故障節點的VIP 轉移到其他節點上。
5). 每個節點的Listener 會同時監聽public 網卡上的 public ip 和VIP
6). 客戶端的tnsnames.Ora 一般會配置指向節點的VIP.
2.4 Clusterware 的日志體系
Oracle Clusterware的輔助診斷，只能從log 和trace 進行。 而且它的日志體系比較復雜。
alert.log:
$ORA_CRS_HOME/log/hostname/alert.Log, 這是首選的查看文件。
Clusterware後台進程日志：
crsd.Log: $ORA_CRS_HOME/log/hostname/crsd/crsd.Log
ocssd.Log: $ORA_CRS_HOME/log/hostname/cssd/ocsd.Log
evmd.Log: $ORA_CRS_HOME/log/hostname/evmd/evmd.Log
Nodeapp日志位置：
$ORA_CRS_HOME/log/hostname/racg/
這裡面放的是nodeapp的日志，包括ONS和VIP，比如：ora.Rac1.ons.Log
工具執行日志：
$ORA_CRS_HOME/log/hostname/client/
Clusterware 提供了許多命令行工具：
比如ocrcheck, ocrconfig,ocrdump,oifcfg和clscfg, 這些工具產生的日志就放在這個目錄下
還有$ORACLE_HOME/log/hostname/client/ 和
$ORACLE_HOME/log/hostname/racg 也有相關的日志。
