RAC模式，兩個(gè)實(shí)例操作同一個(gè)數(shù)據(jù)庫。常用的方式是客戶端連接的時(shí)候分別使用ip1加實(shí)例名和ip2加實(shí)例名的方式連接兩個(gè)實(shí)例。當(dāng)一臺主機(jī)故障之后，ip會切換到另一臺主機(jī)上，但實(shí)例名變化了，仍然無法連接。所以有了服務(wù)名的概念?？蛻舳耸褂?/span>ip加服務(wù)名方式連接數(shù)據(jù)庫可以解決問題，切換比操作系統(tǒng)雙機(jī)快。
但是對于tuxedo長連接的方式，沒有重連接機(jī)制，仍然需要應(yīng)用干預(yù)。
一 集群環(huán)境下的一些特殊問題
1.1 并發(fā)控制
在 集群環(huán)境中， 關(guān)鍵數(shù)據(jù)通常是共享存放的，比如放在共享磁盤上。 而各個(gè)節(jié)點(diǎn)的對數(shù)據(jù)有相同的訪問權(quán)限， 這時(shí)就必須有某種機(jī)制能夠控制節(jié)點(diǎn)對數(shù)據(jù)的訪 問。 Oracle RAC 是利用DLM(Distribute Lock Management) 機(jī)制來進(jìn)行多個(gè)實(shí)例間的并發(fā)控制。
1.2 健忘癥(Amnesia)
集群環(huán)境配置文件不是集中存放的，而是每個(gè)節(jié)點(diǎn)都有一個(gè)本地副本，在集群正常運(yùn)行時(shí)，用戶可以在任何節(jié)點(diǎn)更改集群的配置，并且這種更改會自動同步到其他節(jié)點(diǎn)。
有一種特殊情況： 節(jié)點(diǎn)A 正常關(guān)閉， 在節(jié)點(diǎn)B上修改配置， 關(guān)閉結(jié)點(diǎn)A，啟動結(jié)點(diǎn)B。 這種情況下，修改的配置文件是丟失的， 就是所謂的健忘癥。
1.3 腦裂(Split Brain)
在 集群中，節(jié)點(diǎn)間通過某種機(jī)制(心跳)了解彼此的健康狀態(tài)，以確保各節(jié)點(diǎn)協(xié)調(diào)工作。 假設(shè)只有"心跳"出現(xiàn)問題， 各個(gè)節(jié)點(diǎn)還在正常運(yùn)行， 這時(shí)，每個(gè)節(jié)點(diǎn) 都認(rèn)為其他的節(jié)點(diǎn)宕機(jī)了， 自己是整個(gè)集群環(huán)境中的"唯一建在者"，自己應(yīng)該獲得整個(gè)集群的"控制權(quán)"。 在集群環(huán)境中，存儲設(shè)備都是共享的， 這就意味 著數(shù)據(jù)災(zāi)難， 這種情況就是"腦裂"
解決這個(gè)問題的通常辦法是使用投票算法(Quorum Algorithm). 它的算法機(jī)理如下：
集 群中各個(gè)節(jié)點(diǎn)需要心跳機(jī)制來通報(bào)彼此的"健康狀態(tài)"，假設(shè)每收到一個(gè)節(jié)點(diǎn)的"通報(bào)"代表一票。對于三個(gè)節(jié)點(diǎn)的集群，正常運(yùn)行時(shí)，每個(gè)節(jié)點(diǎn)都會有3票。 當(dāng) 結(jié)點(diǎn)A心跳出現(xiàn)故障但節(jié)點(diǎn)A還在運(yùn)行，這時(shí)整個(gè)集群就會分裂成2個(gè)小的partition。 節(jié)點(diǎn)A是一個(gè)，剩下的2個(gè)是一個(gè)。 這是必須剔除一個(gè) partition才能保障集群的健康運(yùn)行。
對于有3個(gè)節(jié)點(diǎn)的集群， A 心跳出現(xiàn)問題后， B 和 C 是一個(gè)partion，有2票， A只有1票。 按照投票算法， B 和C 組成的集群獲得控制權(quán)， A 被剔除。
如 果只有2個(gè)節(jié)點(diǎn)，投票算法就失效了。 因?yàn)槊總€(gè)節(jié)點(diǎn)上都只有1票。 這時(shí)就需要引入第三個(gè)設(shè) 備：Quorum Device. Quorum Device 通常采用餓是共享磁盤，這個(gè)磁盤也叫作Quorum disk。 這個(gè) Quorum Disk 也代表一票。 當(dāng)2個(gè)結(jié)點(diǎn)的心跳出現(xiàn)問題時(shí)， 2個(gè)節(jié)點(diǎn)同時(shí)去爭取Quorum Disk 這一票， 最早到達(dá)的請求被最先滿 足。 故最先獲得Quorum Disk的節(jié)點(diǎn)就獲得2票。另一個(gè)節(jié)點(diǎn)就會被剔除。
1.4 IO 隔離(Fencing)
當(dāng)集群系統(tǒng)出現(xiàn)"腦裂"問題的時(shí)候，我們可以通過"投票算法"來解決誰獲得集群控制權(quán)的問題。 但是這樣是不夠的，我們還必須保證被趕出去的結(jié)點(diǎn)不能操作共享數(shù)據(jù)。 這就是IO Fencing 要解決的問題。
IO Fencing實(shí)現(xiàn)有硬件和軟件2種方式：
軟 件方式：對于支持SCSI Reserve/Release 命令的存儲設(shè)備， 可以用SG命令來實(shí)現(xiàn)。 正常的節(jié)點(diǎn)使用SCSI Reserve命令" 鎖住"存儲設(shè)備， 故障節(jié)點(diǎn)發(fā)現(xiàn)存儲設(shè)備被鎖住后，就知道自己被趕出了集群，也就是說自己出現(xiàn)了異常情況， 就要自己進(jìn)行重啟，以恢復(fù)到正常狀態(tài)。 這個(gè) 機(jī)制也叫作 Sicide(自殺). Sun 和Veritas 使用的就是這種機(jī)制。
硬 件方式：STONITH(Shoot The Other Node in the Head)， 這種方式直接操作電源開關(guān)，當(dāng)一個(gè)節(jié)點(diǎn)發(fā)生故障時(shí)，另 一個(gè)節(jié)點(diǎn)如果能偵測到，就會通過串口發(fā)出命令，控制故障節(jié)點(diǎn)的電源開關(guān)，通過暫時(shí)斷電，而又上電的方式使故障節(jié)點(diǎn)被重啟動， 這種方式需要硬件支持。
二 RAC 集群
2.1 Clusterware
在單機(jī)環(huán)境下，Oracle是運(yùn)行在OS Kernel 之上的。 OS Kernel負(fù)責(zé)管理硬件設(shè)備，并提供硬件訪問接口。 Oracle 不會直接操作硬件，而是有OS Kernel代替它來完成對硬件的調(diào)用請求。
在 集群環(huán)境下， 存儲設(shè)備是共享的。OS Kernel 的設(shè)計(jì)都是針對單機(jī)的，只能控制單機(jī)上多個(gè)進(jìn)程間的訪問。 如果還依賴OS Kernel的服務(wù)， 就無法保證多個(gè)主機(jī)間的協(xié)調(diào)工作。 這時(shí)就需要引入額外的控制機(jī)制，在RAC中，這個(gè)機(jī)制就是位于Oracle 和 OS Kernel 之間的 Clusterware，它會在OS Kernel之前截獲請求，然后和其他結(jié)點(diǎn)上的Clusterware協(xié)商，最終完成上層的請求。
在 Oracle 10G之前，RAC 所需要的集群件依賴與硬件廠商，比如SUN,HP,Veritas. 從Oracle 10.1版本 中，Oracle 推出了自己的集群產(chǎn)品. Cluster Ready Service(CRS),從此RAC 不在依賴與任何廠商的集群軟件。 在 Oracle 10.2版本中，這個(gè)產(chǎn)品改名為：Oracle Clusterware。
所以我們可以看出， 在整個(gè)RAC 集群中，實(shí)際上有2個(gè)集群環(huán)境的存在，一個(gè)是由Clusterware 軟件組成的集群，另一個(gè)是由Database 組成的集群。
2.2 Clusterware 組成
Oracle Cluster 是一個(gè)單獨(dú)的安裝包，安裝后，在每個(gè)結(jié)點(diǎn)上的Oracle Clusterware 會自動啟動。 Oracle Clusterware的運(yùn)行環(huán)境由2個(gè)磁盤文件(OCR,Voting Disk)，若干進(jìn)程和網(wǎng)絡(luò)元素組成。
2.2.1 磁盤文件:
Clusterware 在 運(yùn)行期間需要兩個(gè)文件：OCR和Voting Disk. 這2個(gè)文件必須存放在共享存儲上。 OCR 用于解決健忘問題，Voting Disk 用于 解決健忘問題。 Oracle 建議使用裸設(shè)備來存放這2個(gè)文件，每個(gè)文件創(chuàng)建一個(gè)裸設(shè)備，每個(gè)裸設(shè)備分配100M左右的空間就夠了。
2.2.1.1 OCR
健忘問題是由于每個(gè)節(jié)點(diǎn)都有配置信息的拷貝，修改節(jié)點(diǎn)的配置信息不同步引起的。 Oracle 采用的解決方法就是把這個(gè)配置文件放在共享的存儲上， 這個(gè)文件就是OCR Disk。
OCR 中 保存整個(gè)集群的配置信息，配置信息以"Key-Value" 的形式保存其中。 在Oracle 10g以前， 這個(gè)文件叫作 Server Manageability Repository(SRVM). 在Oracle 10g， 這部分內(nèi)容被重新設(shè)計(jì)，并重名為OCR.在 Oracle Clusterware 安裝的過程中， 安裝程序會提示用戶指定OCR位置。并且用戶指定的這個(gè)位置會被記錄在/etc/oracle /ocr.Loc(Linux System) 或者/var/opt/oracle/ocr.Loc(Solaris System)文件中。 而在 Oracle 9i RAC中，對等的是srvConfig.Loc文件。 Oracle Clusterware在啟動時(shí)會根據(jù)這里面的內(nèi)容從指定位置 讀入OCR 內(nèi)容。
1). OCR key
整個(gè)OCR 的信息是樹形結(jié)構(gòu)，有3個(gè)大分支。分別是SYSTEM,DATABASE 和CRS。每個(gè)分支下面又有許多小分支。這些記錄的信息只能由root用戶修改。
2) OCR process
Oracle Clusterware 在OCR中存放集群配置信息，故OCR 的內(nèi)容非常的重要，所有對OCR的操作必須確保OCR 內(nèi)容完整性，所以在ORACLE Clusterware運(yùn)行過程中，并不是所有結(jié)點(diǎn)都能操作OCR Disk.
在 每個(gè)節(jié)點(diǎn)的內(nèi)存中都有一份OCR內(nèi)容的拷貝，這份拷貝叫作OCR Cache。 每個(gè)結(jié)點(diǎn)都有一個(gè)OCR Process 來讀寫OCR Cache，但 只有一個(gè)節(jié)點(diǎn)的OCR process能讀寫OCR Disk中的內(nèi)容，這個(gè)節(jié)點(diǎn)叫作OCR Master結(jié)點(diǎn)。 這個(gè)節(jié)點(diǎn)的OCR process 負(fù) 責(zé)更新本地和其他結(jié)點(diǎn)的OCR Cache內(nèi)容。
所 有需要OCR 內(nèi)容的其他進(jìn)程，比如OCSSD,EVM等都叫作Client Process， 這些進(jìn)程不會直接訪問OCR Cache，而是像 OCR Process發(fā)送請求，借助OCR Process獲得內(nèi)容，如果想要修改OCR 內(nèi)容，也要由該節(jié)點(diǎn)的OCR Process像 Master node 的OCR process 提交申請，由Master OCR Process完成物理讀寫，并同步所有節(jié)點(diǎn)OCR Cache 中的內(nèi)容。
2.2.1.2 Voting Disk
Voting Disk 這 個(gè)文件主要用于記錄節(jié)點(diǎn)成員狀態(tài)，在出現(xiàn)腦裂時(shí)，決定那個(gè)Partion獲得控制權(quán)，其他的Partion必須從集群中剔除。在安裝 Clusterware時(shí)也會提示指定這個(gè)位置。 安裝完成后可以通過如下命令來查看Voting Disk位置。
$Crsctl query css votedisk
2.2.2 Clusterware 后臺進(jìn)程
Clusterware 由 若干進(jìn)程組成，其中最重要的3個(gè)是：CRSD,CSSD,EVMD. 在安裝clusterware的最后階段，會要求在每個(gè)節(jié)點(diǎn)執(zhí)行root.sh 腳 本， 這個(gè)腳本會在/etc/inittab 文件的最后把這3個(gè)進(jìn)程加入啟動項(xiàng)，這樣以后每次系統(tǒng)啟動時(shí)，Clusterware 也會自動啟動，其中 EVMD和CRSD 兩個(gè)進(jìn)程如果出現(xiàn)異常，則系統(tǒng)會自動重啟這兩個(gè)進(jìn)程，如果是CSSD 進(jìn)程異常，系統(tǒng)會立即重啟。
1). OCSSD
OCSSD 這 個(gè)進(jìn)程是Clusterware最關(guān)鍵的進(jìn)程，如果這個(gè)進(jìn)程出現(xiàn)異常，會導(dǎo)致系統(tǒng)重啟，這個(gè)進(jìn)程提供 CSS(Cluster Synchronization Service)服務(wù)。 CSS 服務(wù)通過多種心跳機(jī)制實(shí)時(shí)監(jiān)控集群狀態(tài)，提供腦裂保護(hù)等基礎(chǔ) 集群服務(wù)功能。
CSS 服務(wù)有2種心跳機(jī)制： 一種是通過私有網(wǎng)絡(luò)的Network Heartbeat，另一種是通過Voting Disk的Disk Heartbeat.
這 2種心跳都有最大延時(shí)，對于Disk Heartbeat， 這個(gè)延時(shí)叫作IOT (I/O Timeout);對于 Network Heartbeat, 這個(gè)延時(shí)叫MC(Misscount)。 這2個(gè)參數(shù)都以秒為單位，缺省時(shí)IOT大于MC，在默認(rèn)情況下，這2個(gè) 參數(shù)是Oracle 自動判定的，并且不建議調(diào)整。可以通過如下命令來查看參數(shù)值：
$crsctl get css disktimeout
$crsctl get css misscount
注： 除了Clusterware 需要這個(gè)進(jìn)程，在單節(jié)點(diǎn)環(huán)境中如果使用了ASM，也需要這個(gè)進(jìn)程；這個(gè)進(jìn)程用于支持ASM Instance 和 RDBMS Instance之間的通信。 如果在使用了ASM的節(jié)點(diǎn)上安裝RAC，會遇到一個(gè)問題：RAC節(jié)點(diǎn)要求只有一個(gè)OCSSD進(jìn)程，并且應(yīng)該是 運(yùn)行$CRS_HOME目錄下的，這時(shí)就需要先停止ASM，并通過$ORACLE_HOME/bin/localcfig.Sh delete 刪除之前 的inittab 條目。 之前安裝ASM時(shí)，也使用這個(gè)腳本來啟動OCSSD： $ORACLE_HOME/bin /localconfig.Sh add.
2). CRSD
CRSD是實(shí)現(xiàn)"高可用性(HA)"的主要進(jìn)程，它提供的服務(wù)叫作CRS(Cluster Ready Service) 服務(wù)。
Oracle Clusterware是位于集群層的組件，它要為應(yīng)用層資源(CRS Resource) 提供"高可用**"，所以， Oracle Clusterware 必須監(jiān)控這些資源，并在這些資源運(yùn)行異常時(shí)進(jìn)行干預(yù)，包括關(guān)閉，重啟進(jìn)程或者轉(zhuǎn)移服務(wù)。CRSD進(jìn)程提供的就是這些服務(wù)。
所有需要 高可用性 的組件，都會在安裝配置的時(shí)候，以CRS Resource的形式登記到OCR中，而CRSD 進(jìn)程就是根據(jù)OCR中的內(nèi)容，決定監(jiān)控哪些進(jìn)程，如何監(jiān)控，出現(xiàn)問題時(shí)又如何解決。也就是說，CRSD 進(jìn)程負(fù)責(zé)監(jiān)控CRS Resource 的運(yùn)行狀態(tài)，并要啟動，停止，監(jiān)控，Failover這些資源。 默認(rèn)情況下，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 就是說每個(gè)節(jié)點(diǎn)只需要一個(gè)就夠了，比如每個(gè)節(jié)點(diǎn)只有一個(gè)Listener，而Database- Related Resource 就是說這些資源和數(shù)據(jù)庫有關(guān)，不受節(jié)點(diǎn)的限制，比如一個(gè)節(jié)點(diǎn)可以有多個(gè)實(shí)例，每個(gè)實(shí)例可以有多個(gè)Service。
GSD，ONS,VIP 這3個(gè)服務(wù)是在安裝Clusterware的最后，執(zhí)行VIPCA 時(shí)創(chuàng)建并登記到OCR中的。 而Database， Listener， Instance 和Service 是在各自的配置過程中自動或者手動登記到OCR中的。
3). EVMD
EVMD 這 個(gè)進(jìn)程負(fù)責(zé)發(fā)布CRS 產(chǎn)生的各種事件(Event). 這些Event可以通過2種方式發(fā)布給客戶：ONS 和 Callout Script. 用戶 可以自定義回調(diào)腳本，放在特定的目錄下，這樣當(dāng)有某些事件發(fā)生時(shí)，EVMD會自動掃描該目錄，并調(diào)用用戶的腳本，這種調(diào)用是通過racgevt進(jìn)程來完成 的。
EVMD 進(jìn)程除了復(fù)雜發(fā)布事件之外，它還是CRSD 和CSSD 兩個(gè)進(jìn)程之間的橋梁。 CRS 和CSS 兩個(gè)服務(wù)之前的通信就是通過EVMD 進(jìn)程完成的。
4). RACGIMON
RACGIMON 這個(gè)進(jìn)程負(fù)責(zé)檢查數(shù)據(jù)庫健康狀態(tài)，負(fù)責(zé)Service的啟動，停止，故障轉(zhuǎn)移(Failover)。 這個(gè)進(jìn)程會建立到數(shù)據(jù)庫的持久連接，定期檢查SGA中的特定信息，該信息由PMON 進(jìn)程定時(shí)更新。
5). OPROCD
OPROCD 這 個(gè)進(jìn)程也叫作 Process Monitor Daemon. 如果在非Linux 平臺上，并且沒有使用第三方的集群軟件時(shí)，就會看到這個(gè)進(jìn)程。 這 個(gè)進(jìn)程用來檢查節(jié)點(diǎn)的Processor Hang(CPU 掛起), 如果調(diào)度時(shí)間超過1.5秒， 就會認(rèn)為CPU 工作異常，會重啟節(jié)點(diǎn)。 也就是說 這個(gè)進(jìn)程提供 "IO 隔離" 的功能。 從其在Windows 平臺上的服務(wù)名： OraFnceService 也可以看出它的功能。 而在 Linux 平臺上， 是利用Hangcheck-timer 模塊來實(shí)現(xiàn)"IO 隔離"的。
2.3 VIP 原理和特點(diǎn)
Oracle 的TAF 就是建立在VIP 技術(shù)之上的。 IP 和VIP 區(qū)別在與： IP 是利用TCP層超時(shí)， VIP 利用的是應(yīng)用層的立即響應(yīng)。VIP 它是浮動的IP. 當(dāng)一個(gè)節(jié)點(diǎn)出現(xiàn)問題時(shí)會自動的轉(zhuǎn)到另一個(gè)節(jié)點(diǎn)上。
假設(shè)有一個(gè)2個(gè)節(jié)點(diǎn)的RAC，正常運(yùn)行時(shí)每個(gè)節(jié)點(diǎn)上都有一個(gè)VIP。 VIP1 和VIP2. 當(dāng)節(jié)點(diǎn)2發(fā)生故障，比如異常關(guān)系。 RAC 會做如下操作：
1). CRS 在檢測到rac2節(jié)點(diǎn)異常后，會觸發(fā)Clusterware 重構(gòu)，最后把rac2節(jié)點(diǎn)剔除集群，由節(jié)點(diǎn)1組成新的集群。
2). RAC的Failover 機(jī)制會把節(jié)點(diǎn)2的VIP轉(zhuǎn)移到節(jié)點(diǎn)1上，這時(shí)節(jié)點(diǎn)1的PUBLIC 網(wǎng)卡上就有3個(gè)IP 地址： VIP1,VIP2, PUBLIC IP1.
3). 用戶對VIP2的連接請求會被IP層路由轉(zhuǎn)到節(jié)點(diǎn)1
4). 因?yàn)樵诠?jié)點(diǎn)1上有VIP2的地址，所有數(shù)據(jù)包會順利通過路由層，網(wǎng)絡(luò)層，傳輸層。
5). 但是，節(jié)點(diǎn)1上只監(jiān)聽VIP1和public IP1的兩個(gè)IP地址。并沒有監(jiān)聽VIP2，故應(yīng)用層沒有對應(yīng)的程序接收這個(gè)數(shù)據(jù)包，這個(gè)錯(cuò)誤立即被捕獲。
6). 客戶段能夠立即接收到這個(gè)錯(cuò)誤，然后客戶段會重新發(fā)起向VIP1的連接請求。
VIP 特點(diǎn)：
1). VIP 是通過VIPCA腳本創(chuàng)建的
2). VIP 作為Nodeapps類型的CRS Resource 注冊到OCR中，并由CRS 維護(hù)狀態(tài)。
3). VIP 會綁定到節(jié)點(diǎn)的public 網(wǎng)卡上，故public 網(wǎng)卡有2個(gè)地址。
4). 當(dāng)某個(gè)節(jié)點(diǎn)發(fā)生故障時(shí)，CRS 會把故障節(jié)點(diǎn)的VIP 轉(zhuǎn)移到其他節(jié)點(diǎn)上。
5). 每個(gè)節(jié)點(diǎn)的Listener 會同時(shí)監(jiān)聽public 網(wǎng)卡上的 public ip 和VIP
6). 客戶端的tnsnames.Ora 一般會配置指向節(jié)點(diǎn)的VIP.
2.4 Clusterware 的日志體系
Oracle Clusterware的輔助診斷，只能從log 和trace 進(jìn)行。 而且它的日志體系比較復(fù)雜。
alert.log:
$ORA_CRS_HOME\log\hostname\alert.Log, 這是首選的查看文件。
Clusterware后臺進(jìn)程日志：
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
工具執(zhí)行日志：
$ORA_CRS_HOME\log\hostname\client\
Clusterware 提供了許多命令行工具：
比如ocrcheck, ocrconfig,ocrdump,oifcfg和clscfg, 這些工具產(chǎn)生的日志就放在這個(gè)目錄下
還有$ORACLE_HOME\log\hostname\client\ 和
$ORACLE_HOME\log\hostname\racg 也有相關(guān)的日志。
如果使用對稱多處理（symmetric multiprocessing SMP）機(jī)制能夠?qū)?yīng)用程序提供透明的服務(wù)，則應(yīng)該使用RAC也可以得到同樣的效果，而不需要進(jìn)行應(yīng)用程序代碼的任何改動。
當(dāng)一個(gè)節(jié)點(diǎn)發(fā)生失敗，RAC可以排除該Database Instance和node本身，從而保證Database的完整。
下面是一些可擴(kuò)展性的例子：
* 允許更多并發(fā)的批處理。
* 允許更大程度的并發(fā)執(zhí)行。
* 在OLTP系統(tǒng)中可以是連接的用戶大增。
1）可擴(kuò)展性的層次：主要有四個(gè)層次
* hardware 的可擴(kuò)展性：相互連接性是它的關(guān)鍵，這一般依賴于較高的帶寬和較低的延遲。
* OS的可擴(kuò)展性：在OS中，同步方法可以決定系統(tǒng)的可擴(kuò)展性。在一些情況下，硬件的潛在可擴(kuò)展性會因?yàn)镺S無力并發(fā)維持請求的多個(gè)資源而被丟失。
* Database管理系統(tǒng)的可擴(kuò)展性：在并發(fā)結(jié)構(gòu)中的一個(gè)關(guān)鍵因素是并發(fā)是由內(nèi)部影響的還是外部進(jìn)程影響的。此問題的答案影響了同步的機(jī)制。
* 應(yīng)用層次上的可擴(kuò)展性：應(yīng)用程序必須被明確的設(shè)計(jì)為可擴(kuò)展的。當(dāng)系統(tǒng)中如果多數(shù)情況下，每個(gè)session都在更新相同的data，則可能產(chǎn)生瓶頸。這不僅是指RAC，對于single-instance系統(tǒng)也是一樣。
需要明確的是，如果任何一個(gè)層次沒有達(dá)到可擴(kuò)展性，不管其他層次可擴(kuò)展性多強(qiáng)，并發(fā)的Cluster進(jìn)程都可能失敗?？蓴U(kuò)展性不足的典型原因是共享資源的訪問。這使得并發(fā)的操作在此瓶頸上序列化執(zhí)行。這不僅僅是RAC中的局限，而是所有結(jié)構(gòu)中的局限性。
2）scaleup和speedup
* scaleup是工作量和資源都成比例增加時(shí)能維持相同性能水平的能力（相應(yīng)時(shí)間）
Scaleup=(volume parallel)/(volume original)–time for ipc
* speedup是指通過增加資源的數(shù)量完成固定的工作量，獲得執(zhí)行時(shí)間成比例的縮減的效果。
Speedup=(time original)/(time parallel)–time for ipc
其中，ipc是進(jìn)程間通信的簡寫——interprocess communication
RAC Architecture and Concepts
1、RAC軟件原理
在一個(gè)RAC Instance中，會見到一些普通Instance中不存在的后臺進(jìn)程，它們主要是用于維持Database在每個(gè)Instance中的一致性。管理全局資源，具體如下：
* LMON：全局隊(duì)列服務(wù)監(jiān)控進(jìn)程——Global Enqueue Service Monitor
* LMD0：全局隊(duì)列服務(wù)守護(hù)進(jìn)程——Global Enqueue Service Daemon
* LMSx：全局緩沖服務(wù)進(jìn)程，x可以從0到j(luò)——Global Cache Service Processes
* LCK0：鎖進(jìn)程——Lock process
* DIAG：診斷進(jìn)程——Diagnosibility process
在Cluster層，可以找到Cluster Ready Services軟件的主要進(jìn)程，它們在所有平臺上提供標(biāo)準(zhǔn)的Cluster接口，并實(shí)現(xiàn)高可用性的操作。在每個(gè)Cluster node上都可以看到如下的進(jìn)程：
* CRSD和RACGIMON：用于高可用性操作的引擎。
* OCSSD：提供成員節(jié)點(diǎn)和服務(wù)組的訪問
* EVMD：事件檢測進(jìn)程，由oracle用戶運(yùn)行管理
* OPROCD：Cluster的監(jiān)控進(jìn)程
此外還存在幾個(gè)工具用于管理Cluster中全局層次上的各種資源。這些資源是ASM Instance、RAC Database、Services和CRS應(yīng)用節(jié)點(diǎn)。本書中涉及的工具主要有Server Control（SRVCTL）、DBCA和Enterprise Manager。
2、RAC軟件存儲原理
Oracle10g的RAC安裝分為兩個(gè)階段。第一階段是安裝CRS，其次是安裝帶有RAC組件的Database軟件并創(chuàng)建Cluster數(shù)據(jù)庫。CRS軟件使用的Oracle home必須不同于RAC軟件使用的home。盡管可以將Cluster中CRS和RAC軟件通過使用Cluster文件系統(tǒng)共享存儲，但是軟件總是按一定規(guī)則安裝在每個(gè)節(jié)點(diǎn)的本地文件系統(tǒng)中。這支持在線補(bǔ)丁的升級，并消除了單節(jié)點(diǎn)軟件造成的失敗。另外有兩個(gè)必須存儲在共享的存儲設(shè)備中：
* voting file：其本質(zhì)上是用于Cluster synchronization Services守護(hù)進(jìn)程進(jìn)行節(jié)點(diǎn)信息的監(jiān)控。大小約為20MB。
* Oracle Cluster Registry（OCR）文件：也是CRS關(guān)鍵的組成部分。用于維護(hù)在Cluster中高可用性組件的信息。例如，Cluster節(jié)點(diǎn)列表，Cluster數(shù)據(jù)庫Instance到節(jié)點(diǎn)的映射和CRS應(yīng)用資源的列表（如Services、虛擬內(nèi)部鏈接協(xié)議地址等）。此文件是通過SRVCTL類似的管理工具自動維護(hù)的。其大小約100MB。
voting file和OCR file是不能被存儲在ASM中的，因?yàn)樗鼈儽仨氃谌魏蜲racle Instance啟動前就可以被訪問。并且，兩者必須是在冗余的、可靠的存儲設(shè)備中存放，如RAID。推薦最好的做法是將這些文件放在裸磁盤上。
3、OCR的結(jié)構(gòu)
Cluster的配置信息是在OCR中維護(hù)的。OCR依賴分布式的共享緩存結(jié)構(gòu)用于優(yōu)化關(guān)于Cluster知識庫的查詢。在Cluster中的每個(gè)節(jié)點(diǎn)都通過OCR進(jìn)程訪問OCR緩存在其內(nèi)存中維護(hù)著一個(gè)副本。事實(shí)上在Cluster中，只有一個(gè)OCR進(jìn)程對共享存儲中的OCR進(jìn)行讀寫操作。此進(jìn)程負(fù)責(zé)刷新（refresh）其自己擁有的本地緩存以及Cluster中其他節(jié)點(diǎn)的OCR cache。對于涉及到Cluster知識庫的訪問，OCR客戶端直接訪問本地OCR進(jìn)程。當(dāng)客戶端需要更新OCR時(shí)，它們將通過本地OCR進(jìn)程與那個(gè)扮演讀寫OCR文件的進(jìn)程進(jìn)行交互。
OCR客戶端應(yīng)用有：Oracle通用安裝器（OUI）、SRVCTL、企業(yè)管理器（EM）、DBCA、DBUA、NetCA和虛擬網(wǎng)絡(luò)協(xié)議助理（VIPCA）。此外，OCR維護(hù)管理著CRS內(nèi)部中定義的各種應(yīng)用程序的資源的依賴和狀態(tài)信息，特別是Database、Instance、Services和節(jié)點(diǎn)的應(yīng)用程序。
配置文件的名字是ocr.loc，并且配置文件變量是ocrconfig_loc。Cluster 知識庫的位置是不受限于裸設(shè)備的。可以將OCR放置在由Cluster file system管理的共享存儲設(shè)備上。
note：OCR也可用于在ASM的單Instance中作為配置文件，每個(gè)節(jié)點(diǎn)有一個(gè)OCR。
4、RAC Database存儲原理
與single-Instance Oracle的存儲方式最主要的不同之處在于RAC存儲必須將所有RAC中數(shù)據(jù)文件存放在共享設(shè)備中（裸設(shè)備或是Cluster文件系統(tǒng)）以便于訪問相同Database的Instance能夠共享。必須為每個(gè)Instance創(chuàng)建至少兩個(gè)redo log組，并且所有的redo log組必須也存儲在共享設(shè)備中，從而為了crash恢復(fù)的目的。每個(gè)Instance的在線redo log groups被稱作一個(gè)Instance的在線redo 線程。
此外，必須為每個(gè)Instance創(chuàng)建一個(gè)共享的undo表空間用于Oracle推薦的undo自動管理特點(diǎn)。每個(gè)undo表空間必須是對所有Instance共享的，主要用于恢復(fù)的目的。
歸檔日志不能被存放在裸設(shè)備上，因?yàn)槠涿亲詣赢a(chǎn)生的，并且每個(gè)是不一致的。因此需要存儲在一個(gè)文件系統(tǒng)中。如果使用Cluster file system（CFS），則可以在任何時(shí)間在任何node上訪問這些歸檔文件。如果沒有使用CFS，就不得不使其他Cluster成員在恢復(fù)時(shí)那些歸檔日志是可用的，例如通過網(wǎng)絡(luò)文件系統(tǒng)（NFS）來實(shí)現(xiàn)。如果使用推薦的flash recovery area特性，則其必須被存儲在共享目錄下，以便于所有的Instance能夠訪問。（共享目錄可以是一個(gè)ASM磁盤組，或是一個(gè)CFS）。
5、RAC和共享存儲技術(shù)
存儲是網(wǎng)格技術(shù)中的關(guān)鍵組成部分。傳統(tǒng)上，存儲都直接依附在每個(gè)Server（directly attached to each individual Server DAS）上。在過去的幾年來，更靈活的存儲出現(xiàn)并得到應(yīng)用，主要是通過存儲空間網(wǎng)絡(luò)或是正規(guī)的以太網(wǎng)來實(shí)現(xiàn)訪問。這些新的存儲方式使得多個(gè)Servers訪問相同的磁盤集合成為可能，在分布式環(huán)境中，可以獲得簡單的存取。
storage area network（SAN）代表了數(shù)據(jù)存儲技術(shù)在這一點(diǎn)的演進(jìn)。傳統(tǒng)上，C/S系統(tǒng)中，數(shù)據(jù)被存儲在Server內(nèi)部或是依附它的設(shè)備中。隨后，進(jìn)入了network attached storage（NAS）階段，這使得存儲設(shè)備與Server和直接連接它們的網(wǎng)絡(luò)向分離。它在SAN遵循的原則進(jìn)一步允許存儲設(shè)備存在于各自的網(wǎng)絡(luò)中，并直接通過高速的媒介進(jìn)行交換。用戶可以通過Server系統(tǒng)對存儲設(shè)備的數(shù)據(jù)進(jìn)行訪問，Server 系統(tǒng)與本地網(wǎng)絡(luò)（LAN）和SAN相互連接。
文件系統(tǒng)的選擇是RAC的關(guān)鍵。傳統(tǒng)的文件系統(tǒng)不支持多系統(tǒng)的并行掛載。因此，必須將文件存儲在沒有任何文件系統(tǒng)的裸卷標(biāo)或是支持多系統(tǒng)并發(fā)訪問的文件系統(tǒng)中。
因此，三個(gè)主要的方法用于RAC的共享存儲有：
* 裸卷標(biāo)：既是一些直接附加的裸設(shè)備，需要用于存儲，并以block模式進(jìn)程操作。
* Cluster file system：也需要以block模式進(jìn)程存取。一個(gè)或多個(gè)Cluster file 系統(tǒng)可以被用于存儲所有的RAC文件。
* 自動存儲管理（ASM）：對于Oracle Database files，ASM是一個(gè)輕便的、專用的、最佳化的Cluster file system。
6、Oracle Cluster file system
Oracle Cluster file system（OCFS）是一個(gè)共享文件系統(tǒng)，專門為Oracle RAC設(shè)計(jì)。OCFS排除了Oracle Database files被連接到邏輯磁盤上的需要，并使得所有的節(jié)點(diǎn)共享一個(gè)ORACLE Home，而不需每個(gè)node在本地有一個(gè)副本。OCFS卷標(biāo)可以橫跨一個(gè)或多共享disks，用于冗余和性能的增強(qiáng)。
下面時(shí)可放入OCFS中的文件類表：
* Oracle software的安裝文件：在10g中，此設(shè)置只在windows 2000中支持。說是后面的版本會提供在Linux中的支持，但我還沒具體看。
* Oracle 文件（控制文件、數(shù)據(jù)文件、redo logs文件，bfiles等）
* 共享配置文件（spfile）
* 在Oracle運(yùn)行期間，由Oracle創(chuàng)建的文件。
* voting和OCR文件
Oracle Cluster file system對開發(fā)人員和用戶時(shí)免費(fèi)的?？蓮墓俜骄W(wǎng)站下載。
7、自動存儲管理（ASM）
是10g的新特性。它提供了一個(gè)縱向的統(tǒng)一管理的文件系統(tǒng)和卷標(biāo)管理器，專門用于建立Oracle Database 文件。ASM可以提供單個(gè)SMP機(jī)器的管理或是貫穿多個(gè)Oracle RAC的Cluster節(jié)點(diǎn)。
ASM無需再手動調(diào)節(jié)I/O，會自動的分配 I/O 負(fù)載到所有的可用資源中，從而優(yōu)化性能。通過允許增加Database大小而不需shutdown數(shù)據(jù)庫來調(diào)節(jié)存儲分配，來輔助DBA管理動態(tài)數(shù)據(jù)庫環(huán)境。
ASM可以維護(hù)數(shù)據(jù)的冗余備份，從而提高故障的容錯(cuò)。它也可以被安裝到可靠的存儲機(jī)制中。
8、選擇RAW或CFS
* CFS的優(yōu)點(diǎn)：對于RAC的安裝和管理非常簡單；對RAC使用Oracle managed files（OMF）；single Oracle軟件安裝；在Oracle data files上可以自動擴(kuò)展；當(dāng)物理節(jié)點(diǎn)失敗時(shí)，對歸檔日志的統(tǒng)一訪問。
* 裸設(shè)備的使用：一般會用于CFS不可用或是不被Oracle支持的情況下；它提供了最好的性能，不需要在Oracle和磁盤之間的中間層；如果空間被耗盡，裸設(shè)備上的自動擴(kuò)展將失?。籄SM、邏輯存儲管理器或是邏輯卷標(biāo)管理其可以簡化裸設(shè)備的工作，它們也允許加載空間到在線的裸設(shè)備上，可為裸設(shè)備創(chuàng)建名字，從而便于管理。
9、RAC的典型Cluster棧
在Cluster中的每個(gè)節(jié)點(diǎn)都需要一個(gè)被支持的相互連接的軟件協(xié)議來支持內(nèi)部Instance的交互，同時(shí)需要TCP/IP支持CRS的輪詢。所有的UNIX平臺在千兆以太網(wǎng)上使用user datagram protocol（UDP）作為主要的協(xié)議并進(jìn)行RAC內(nèi)部Instance 的IPC交互。其他支持的特有協(xié)議包括用于SCI和Sunfire的連接交互的遠(yuǎn)程共享內(nèi)存協(xié)議和超文本協(xié)議，用于超光纖交互。在任何情況下，交互必須能被平臺的Oracle所辨識。
使用Oracle clusterware，可以降低安裝并支持并發(fā)癥。但如果用戶使用非以太交互，或開發(fā)了依賴clusterware的應(yīng)用程序在RAC上，可能需要vendor clusterware。
同交互連接一樣，共享存儲方案必須被當(dāng)前平臺的Oracle所辨識。如果在目標(biāo)平臺上，CFS可用，Database area和flash recovery area都可以被創(chuàng)建到CFS或ASM上。如果在目標(biāo)平臺上，CFS不可用，則Database area可以創(chuàng)建在ASM或是裸設(shè)備上（需要卷標(biāo)管理器）并且flash recovery area必須被創(chuàng)建在ASM中。
10、RAC certification Matrix：它設(shè)計(jì)用于處理任何認(rèn)證問題。可以使用matrix回答任何RAC相關(guān)的認(rèn)證問題。具體使用步驟如下：
* 連接并登陸 http://metalink.oracle.com
* 點(diǎn)擊菜單欄的“certify and availability”按鈕
* 點(diǎn)擊“view certifications by product”連接
* 選擇RAC
* 選擇正確的平臺
11、必要的全局資源
一個(gè)single-Instance環(huán)境，鎖坐標(biāo)通向一個(gè)共享的資源就像表中的一行。lock避免了兩個(gè)進(jìn)程同事修改相同的資源。
在RAC環(huán)境中，內(nèi)部節(jié)點(diǎn)的同步時(shí)關(guān)鍵，因?yàn)樗S持著不同節(jié)點(diǎn)中各自進(jìn)程的一致性，避免其在同時(shí)修改相同的資源數(shù)據(jù)。內(nèi)部節(jié)點(diǎn)的同步確保每個(gè)Instance看到buffer cache中block的最近的版本。上圖中顯示了當(dāng)不存在加鎖的情況。
1）全局資源的協(xié)調(diào)
cluster操作要求在所有Instance中對控制共享資源的訪問進(jìn)行同步。RAC使用Global Resource Directory來記錄cluster Database中資源的使用信息。Global Cache Service（GCS）和Global Enqueue Service（GES）管理GRD中的信息。
每個(gè)Instance在其本地的SGA中維護(hù)GRD的一部分。GCS和GES指定一個(gè)Instance管理特殊資源的所有信息，它被稱為資源的master。每個(gè)Instance都知道resource的Instance masters。
維護(hù)RAC的活動中的cache的依附性（cache coherency）是非常重要的。所謂cache coherency是保持在不同Oracle Instances中的多個(gè)block版本的一致性的技術(shù)。GCS通過所謂的cache融合算法來實(shí)現(xiàn)cache coherency。
GES管理所有非cache 融合算法的內(nèi)部Instance資源操作和Oracle入隊(duì)機(jī)制的狀態(tài)軌跡。GES主要的控制的資源是字典cache locks和library cache locks。同時(shí)，它還對所有死鎖敏感的隊(duì)列和資源起到死鎖檢測的作用。
2）Global cache coordination實(shí)例
假設(shè)某data block被第一個(gè)節(jié)點(diǎn)修改，成為臟數(shù)據(jù)。并且在clusterwide中，只有一個(gè)block copy版本，其內(nèi)容用SCN號代替了。則具體的步驟如下：
① 第二個(gè)Instance視圖修改該block，向GCS提出請求。
② GCS向block的holder（持有者）提交請求。在此，第一個(gè)Instance就是holder。
③ 第一個(gè)Instance接到消息，并將block發(fā)送給第二個(gè)Instance。第一個(gè)Instance保存臟buffer用于恢復(fù)的目的。block的臟鏡像被稱作block的past image。一個(gè)past image block將不能進(jìn)一步被改變。
④收到block后，第二個(gè)Instance通知GCS，告知已經(jīng)holds該block。
3）write to disk coordination：example
在cluster結(jié)構(gòu)中的Instances中的caches中，可能存在同一個(gè)block的不同的修改版本。由GCS管理的寫協(xié)議確保了只有最近一個(gè)版本被寫入磁盤中。它同時(shí)需要確保其他之前的版本從其他cache中被清洗。一個(gè)寫磁盤的請求可以從任意一個(gè)Instance上發(fā)起，無論它是保存了block的當(dāng)前版本還是過去的版本。假設(shè)第一個(gè)Instance hold過去的block鏡像，請求Oracle將buffer寫入磁盤，如上圖，過程如下：
①第一個(gè)Instance發(fā)送一個(gè)寫請求給GCS
②GCS將請求轉(zhuǎn)給第二個(gè)Instance，當(dāng)前該block的holder
③第二個(gè)Instance接到寫請求后將block寫入磁盤
④第二個(gè)Instance通知GCS，告知其寫操作完成
⑤當(dāng)接到GCS接到通知后，GCS命令所有的過去的鏡像的holders刪除其過去的鏡像。此鏡像將不會在因恢復(fù)而需要。
12、RAC和Instance/crash recovery
1）當(dāng)一個(gè)Instance失敗，當(dāng)該失敗被其他Instance檢測到，第二個(gè)Instance將會執(zhí)行下面的恢復(fù)操作：
①在恢復(fù)的第一階段，GES重新灌入隊(duì)列
②GCS也重新灌入其資源。GCS進(jìn)程只重新灌入那些失去其控制的資源。在這期間，所有的GCS資源請求和寫請求都臨時(shí)被掛起。然而，事務(wù)可以繼續(xù)修改data blocks，只要這些事務(wù)已經(jīng)獲得了必要的資源。
③當(dāng)隊(duì)列被重新配置后，一個(gè)活動的Instance可以獲得占有該Instance恢復(fù)隊(duì)列。因此，當(dāng)GCS資源被重新灌入的同時(shí)，SMON確定需要被恢復(fù)的blocks的集合。這個(gè)集合被稱作恢復(fù)集。因?yàn)椋褂胏ache 融合算法，一個(gè)Instance傳送這些blocks的內(nèi)容到請求的Instance，而不需要將這些blocks寫入磁盤。這些blocks在磁盤上的版本可能不包含其他Instance進(jìn)程的data的修改操作的blocks。這意味著SMON需要合并所有失敗的Instance的redo logs來確定恢復(fù)集。這是因?yàn)橐粋€(gè)失敗的線程可能導(dǎo)致一個(gè)在redo 中的hole（洞）需要用指定的block填補(bǔ)。所以失敗的Instance的redo 線程不能被連續(xù)的應(yīng)用。同時(shí)，活動的Instances的redo 線程不需恢復(fù)，因?yàn)镾MON可以使用過去和當(dāng)前的通信緩沖的鏡像。
④用于恢復(fù)的緩沖空間被分配，并且那些之前讀取redo logs被辨識的資源被聲明為恢復(fù)資源。這避免了其他Instance訪問這些資源。
⑤所有在隨后的恢復(fù)操作中需要的資源被獲得，并且GRD當(dāng)前是不凍結(jié)的。任何不需恢復(fù)的data block現(xiàn)在可以被訪問。所以當(dāng)前系統(tǒng)時(shí)部分可用的。此時(shí)，假設(shè)有過去或當(dāng)前的blocks鏡像需要被恢復(fù)，而其在cluster Database中的其他caches中，對于這些特殊的blocks，最近的鏡像是開始恢復(fù)點(diǎn)。如果對于要恢復(fù)的block，過去鏡像和當(dāng)前鏡像緩沖都不在活動的Instance的caches中，則SMON將寫入一個(gè)log，表明合并失敗。SMON會對第三步中辨識的每個(gè)block進(jìn)行恢復(fù)和寫入，在恢復(fù)之后會馬上釋放資源，從而使更多的資源在恢復(fù)時(shí)可以被使用。
當(dāng)所有的block被恢復(fù)，占用的恢復(fù)資源被釋放，則系統(tǒng)再次可用。
note：在恢復(fù)中，log合并的開支和失敗的Instances的數(shù)目是成比例的，并且與每個(gè)Instance的redo logs的大小有關(guān)。
2）Instance recovery和Database availability
上圖顯示了在進(jìn)行Instance恢復(fù)時(shí)，每一步執(zhí)行時(shí)數(shù)據(jù)庫的可用程度：
A. RAC運(yùn)行在多節(jié)點(diǎn)上
B. 有節(jié)點(diǎn)失敗被檢測到
C. GRD的隊(duì)列部分被重新設(shè)置；資源管理被重新分配到活動的nodes。此操作的執(zhí)行比較快
D. GRD的緩沖部分被重新設(shè)置，SMON讀取失敗Instance的redo logs辨識那些需要恢復(fù)的blocks的集合
E. SMON向GRD發(fā)起請求，獲得所有在需要恢復(fù)的blocks集合中的Database blocks。當(dāng)請求結(jié)束，所有的其他的blocks都可被訪問了
F. Oracle執(zhí)行滾動的向前恢復(fù)。失敗線程的redo logs被應(yīng)用到Database，并且那些被完全恢復(fù)的blocks將馬上可以被訪問
G. Oracle執(zhí)行滾回恢復(fù)。對于尚未提交的事務(wù)，undo blocks被應(yīng)用到Database中
H. Instance的恢復(fù)完成，所有的data可以被訪問
13、有效的內(nèi)部節(jié)點(diǎn)行級鎖
Oracle支持有效的行級鎖。這些行級鎖主要是在DML操作時(shí)被創(chuàng)建，例如UPDATE。這些鎖被持有，直到事務(wù)被提交或回滾。任何請求同行的lock的進(jìn)程都將被掛起。
cache融合算法的塊傳輸獨(dú)立于這些user可見的行級鎖。GCS對blocks的傳輸是一個(gè)底層的操作，無需當(dāng)代行級鎖被釋放就開始進(jìn)行。blocks可能被從一個(gè)Instance傳輸?shù)狡渌渌鸌nstances，同時(shí)該blocks可能被加鎖。
GCS提供對data blocks的訪問，允許多個(gè)事務(wù)的并發(fā)進(jìn)行。
14、RAC的額外的內(nèi)存需求
RAC特有的內(nèi)存多數(shù)是在SGA創(chuàng)建時(shí)從shared pool中分配的。因?yàn)閎locks可能跨越Instances被緩沖，必須要求更大的緩沖區(qū)。因此，當(dāng)將single Instance的Database遷移到RAC中時(shí)，保持每個(gè)Instance的請求工作量都能通single-instance時(shí)的情況，則需要對運(yùn)行RAC的Instance增大10%的buffer cache和15%的shared pool。這些值只是基于RAC大小的經(jīng)驗(yàn)，一個(gè)初始的嘗試值。一般會大于此值。
如果正在使用推薦的自動內(nèi)存管理特性，可以通過修改SGA_TARGET初始參數(shù)來設(shè)置。但考慮到同樣數(shù)量的user訪問被分散到多個(gè)nodes中，每個(gè)Instance的內(nèi)存需求可以被降低。
實(shí)際資源的使用可以通過查詢每個(gè)Instance中的GCS和GES實(shí)體中的視圖V$RESOURCE_LIMIT視圖CURRENT_UTILIZATION和MAX_UTILIZATION字段，具體語句為：
SELECT resource_name, current_utilization, max_utilization FROM v$resource_limit WHERE resource_name like ‘g%s_%’;
15、RAC與并發(fā)執(zhí)行
Oracle的優(yōu)化器是基于執(zhí)行訪問代價(jià)的，這就考慮了并發(fā)執(zhí)行的代價(jià)，并將其作為獲得理想的執(zhí)行計(jì)劃的一個(gè)部件。
在RAC環(huán)境中，優(yōu)化器的并發(fā)選擇是由內(nèi)部節(jié)點(diǎn)和外部節(jié)點(diǎn)并發(fā)兩類組成的。例如，一個(gè)特殊的查詢請求需要六個(gè)查詢進(jìn)程完成，并且在本地節(jié)點(diǎn)有六個(gè)并發(fā)的從屬執(zhí)行進(jìn)程都是idle的，則查詢通過使用本地資源執(zhí)行，從而獲得結(jié)果。這闡述了有效地內(nèi)部節(jié)點(diǎn)并發(fā)，也無需多節(jié)點(diǎn)并發(fā)的查詢協(xié)調(diào)的開支。如果本地節(jié)點(diǎn)中只有兩個(gè)并發(fā)執(zhí)行從屬進(jìn)程可用，則這兩個(gè)進(jìn)程和其他節(jié)點(diǎn)的四個(gè)進(jìn)程共同執(zhí)行查詢。在這種情況下，內(nèi)部節(jié)點(diǎn)和外部節(jié)點(diǎn)并發(fā)都被使用到，從而加速查詢。
在真實(shí)環(huán)境的決策支持應(yīng)用程序中，查詢不能通過各種查詢servers得到較好的劃分。所以有些并發(fā)執(zhí)行servers完成其任務(wù)后先于其他servers變?yōu)閕dle狀態(tài)。Oracle并發(fā)執(zhí)行技術(shù)動態(tài)監(jiān)測idle的進(jìn)程，并將超載進(jìn)程的隊(duì)列表中的任務(wù)分配任務(wù)給處于idle狀態(tài)的進(jìn)程。這樣，Oracle有效的再分配了所有進(jìn)程的查詢工作量。RAC進(jìn)一步擴(kuò)展這個(gè)效率到整個(gè)cluster上。
16、全局動態(tài)性能視圖
全局動態(tài)性能視圖顯示所有開啟并訪問RAC Database的Instances相關(guān)的信息。而標(biāo)準(zhǔn)動態(tài)性能視圖只顯示了本地Instance的相關(guān)信息。
對于所有V$類型的視圖，都會對應(yīng)一個(gè)GV$視圖，除了幾個(gè)別的特殊情況。除了V$視圖中的columns，GV$視圖中包含了一個(gè)名為INST_ID的額外的column，顯示了RAC中的Instance number?？梢栽谌魏伍_啟的Instance上訪問GV$。
為了查詢GV$視圖，每個(gè)Instance上的初始PARALLEL_MAX_SERVERS初始化參數(shù)至少設(shè)置為1 。這是由于對GV$的查詢使用了特殊的并發(fā)執(zhí)行。并發(fā)執(zhí)行的協(xié)調(diào)者運(yùn)行在客戶端連接的Instance上，并且每個(gè)Instance上分配一個(gè)slave用于查詢其潛在的V$視圖。如果有一個(gè)Instance上的PARALLEL_MAX_SERVERS被設(shè)置為0，則無法獲得該node的信息，同理，如果所有的并發(fā)servers非常忙，則也無法獲得結(jié)果。在以上兩種情況下，不會獲得提示或錯(cuò)誤信息。
17、RAC和Service
18、虛擬IP地址和RAC
