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