OracleRAC 是多個單實例在配置意義上的擴展，實現(xiàn)由兩個或者多個節(jié)點（實例）使用一個共同的共享數(shù)據(jù)庫（例如，一個數(shù)據(jù)庫同時安裝多個實例并打開）。在這種情況下，每一個單獨的實例有它自己的 cpu 和物理內(nèi)存，也有自己的 SGA 和后臺進程。和傳統(tǒng)的 oracle 實例相比，在系統(tǒng)全局區(qū)（SYSTEM CLOBAL AREA,SGA）與后臺進程有著顯著的不同。最大的不同之處在于多了一個GRD,GRD內(nèi)存塊主要是記錄此rac有多少個集群數(shù)據(jù)庫與系統(tǒng)資源，同時也會記錄數(shù)據(jù)塊的相關信息，因為在 rac 架構中，每個數(shù)據(jù)塊在每一個 SGA 中都有一份副本，而 rac 必須知道這些數(shù)據(jù)塊的位置，版本，分布以及目前的狀態(tài)，這些信息就存放在 GRD 中，但 GRD 只負責存放不負責管理，管理的責任則交給后臺進程 GCS 和 GES 來進行。Oracle 的多個實例訪問一個共同的共享數(shù)據(jù)庫。每個實例都有自己的 SGA、PGA 和后臺進程，這些后臺進程應該是熟悉的，因為在 RAC 配置中，每個實例將需要這些后臺進程運行支撐的?？梢詮囊韵聨讉€方面了解 RAC工作原理和運行機制。
SCN 是 Oracle 用來跟蹤數(shù)據(jù)庫內(nèi)部變化發(fā)生先后順序的機制，可以把它想象成一個高精度的時鐘，每個 Redo日志條目，Undo Data Block，Data Block 都會有 SCN 號。 Oracle 的Consistent-Read， Current-Read，Multiversion-Block 都是依賴 SCN 實現(xiàn)。在 RAC 中，有 GCS 負責全局維護 SCN 的產(chǎn)生，缺省用的是 Lamport SCN 生成算法，該算法大致原理是： 在所有節(jié)點間的通信內(nèi)容中都攜帶 SCN， 每個節(jié)點把接收到的 SCN 和本機的 SCN 對比，如果本機的 SCN 小，則調(diào)整本機的 SCN 和接收的一致，如果節(jié)點間通信不多，還會主動地定期相互通報。 故即使節(jié)點處于 Idle 狀態(tài)，還是會有一些 Redo log 產(chǎn)生。 還有一個廣播算法（Broadcast），這個算法是在每個 Commit 操作之后，節(jié)點要想其他節(jié)點廣播 SCN，雖然這種方式會對系統(tǒng)造成一定的負載，但是確保每個節(jié)點在 Commit 之后都能立即查看到 SCN.這兩種算法各有優(yōu)缺點，Lamport 雖然負載小，但是節(jié)點間會有延遲，廣播雖然有負載，但是沒有延遲。Oracle 10g RAC 缺省選用的是 BroadCast 算法，可以從 alert.log 日志中看到相關信息：Picked broadcast on commit scheme to generate SCNS。
全局隊列服務（GES）主要負責維護字典緩存和庫緩存的一致性。字典緩存是實例的 SGA 內(nèi)所存儲的對數(shù)據(jù)字典信息的緩存，用于高速訪問。由于該字典信息存儲在內(nèi)存中，因而在某個節(jié)點上對字典進行的修改（如DDL)必須立即被傳播至所有節(jié)點上的字典緩存。GES 負責處理上述情況，并消除實例間出現(xiàn)的差異。處于同樣的原因，為了分析影響這些對象的 SQL 語句，數(shù)據(jù)庫內(nèi)對象上的庫緩存鎖會被去掉。這些鎖必須在實例間進行維護，而全局隊列服務必須確保請求訪問相同對象的多個實例間不會出現(xiàn)死鎖。LMON、LCK 和 LMD 進程聯(lián)合工作來實現(xiàn)全局隊列服務的功能。GES 是除了數(shù)據(jù)塊本身的維護和管理（由 GCS 完成）之外，在 RAC 環(huán)境中調(diào)節(jié)節(jié)點間其他資源的重要服務。為了保證集群中的實例的同步，兩個虛擬服務將被實現(xiàn)：全局排隊服務（GES），它負責控制對鎖的訪問。
全局內(nèi)存服務（GCS)，控制對數(shù)據(jù)塊的訪問。GES 是 分布式鎖管理器(DLM)的擴展，它是這樣一個機制，可以用來管理 oracle 并行服務器的鎖和數(shù)據(jù)塊。在一個群集環(huán)境中，你需要限制對數(shù)據(jù)庫資源的訪問，這些資源在單 instance 數(shù)據(jù)庫中被 latches 或者 locks 來保護。比如說，在數(shù)據(jù)庫字典內(nèi)存中的對象都被隱性鎖所保護，而在庫高速緩存中的對象在被引用的時候，必須被 pin 所保護。在 RAC 群集中，這些對象代表了被全局鎖所保護的資源。GES 是一個完整的 RAC 組件，它負責和群集中的實例全局鎖進行溝通，每個資源有一個主節(jié)點實例，這個實例記錄了它當前的狀態(tài)。而且，資源的當前的狀態(tài)也記錄在所有對這個資源有興趣的實例上。GCS,是另一個 RAC 組件，負責協(xié)調(diào)不同實例間對數(shù)據(jù)塊的訪問。對這些數(shù)據(jù)塊的訪問以及跟新都記錄在全局目錄中（GRD）,這個全局目錄是一個虛擬的內(nèi)存結構，在所有的實例中使用擴張。每個塊都有一個master實例，這個實例負責對GSD的訪問進行管理，GSD里記錄了這個塊的當前狀態(tài)信息。
GCS 是 oracle 用來實施 Cache fusion 的機制。被 GCS 和 GES 管理的塊和鎖叫做資源。對這些資源的訪問必須在群集的多個實例中進行協(xié)調(diào)。這個協(xié)調(diào)在實例層面和數(shù)據(jù)庫層面都有發(fā)生。實例層次的資源協(xié)調(diào)叫做本地資源協(xié)調(diào)；數(shù)據(jù)庫層次的協(xié)調(diào)叫做全局資源協(xié)調(diào)。
本地資源協(xié)調(diào)的機制和單實例 oracle 的資源協(xié)調(diào)機制類似，包含有塊級別的訪問，空間管理，dictionary cache、library cache 管理，行級鎖，SCN 發(fā)生。全局資源協(xié)調(diào)是針對 RAC 的，使用了 SGA 中額外的內(nèi)存組件、算法和后臺進程。GCS 和 GES 從設計上就是在對應用透明的情況下設計的。換一句話來說，你不需要因為數(shù)據(jù)庫是在 RAC上運行而修改應用,在單實例的數(shù)據(jù)庫上的并行機制在 RAC 上也是可靠地。
支持 GCS 和 GES 的后臺進程使用私網(wǎng)心跳來做實例之間的通訊。這個網(wǎng)絡也被 Oracle 的 群集組件使用，也有可能被 群集文件系統(tǒng)（比如 OCFS)所使用。GCS 和 GES 獨立于 Oracle 群集組件而運行。但是，GCS 和GES 依靠 這些群集組件獲得群集中每個實例的狀態(tài)。如果這些信息不能從某個實例獲得，這個實例將被關閉。這個關閉操作的目的是保護數(shù)據(jù)庫的完整性，因為每個實例需要知道其他實例的情況，這樣可以更好的確定對數(shù)據(jù)庫的協(xié)調(diào)訪問。
GES 控制數(shù)據(jù)庫中所有的 library cache 鎖和 dictionary cache 鎖。這些資源在單實例數(shù)據(jù)庫中是本地性的，但是到了 RAC 群集中變成了全局資源。全局鎖也被用來保護數(shù)據(jù)的結構，進行事務的管理。一般說來，事務和表鎖 在 RAC 環(huán)境或是 單實例環(huán)境中是一致的。
Oracle 的各個層次使用相同的 GES 功能來獲得，轉(zhuǎn)化以及釋放資源。在數(shù)據(jù)庫啟動的時候，全局隊列的個數(shù)將被自動計算。GES 使用后臺進程 LMD0 和 LCK0 來執(zhí)行它的絕大多數(shù)活動。一般來說，各種進程和本地的 LMD0 后臺進程溝通來管理全局資源。本地的 LMD0 后臺進程與 別的實例上的 LMD0 進程進行溝通。
LCK0 后臺進程用來獲得整個實例需要的鎖。比如，LCK0 進程負責維護 dictionary cache 鎖。影子進程(服務進程） 與這些后臺進程通過 AST(異步陷阱）消息來通信。異步消息被用來避免后臺進程的阻塞，這些后臺進程在等待遠端實例的的回復的時候?qū)⒆枞?。后臺進程也能 發(fā)送 BAST(異步鎖陷阱）來鎖定進程，這樣可以要求這些進程把當前的持有鎖置為較低級限制的模式。資源是內(nèi)存結構，這些結構代表了數(shù)據(jù)庫中的組件，對這些組件的訪問必須為限制模式或者串行化模式。換一句話說，這個資源只能被一個進程或者一直實例并行訪問。如果這個資源當前是處于使用狀態(tài)，其他想訪問這個資源的進程必須在隊列中等待，直到資源變得可用。隊列是內(nèi)存結構，它負責并行化對特殊資源的訪問。如果這些資源只被本地實例需求，那么這個隊列可以本地來獲得，而且不需要協(xié)同。但是如果這個資源被遠程實例所請求，那么本地隊列必須變成全球化。
在單機環(huán)境下，Oracle 是運行在 OS Kernel 之上的。 OS Kernel 負責管理硬件設備，并提供硬件訪問接口。Oracle 不會直接操作硬件，而是有 OS Kernel 代替它來完成對硬件的調(diào)用請求。在集群環(huán)境下， 存儲設備是共享的。OS Kernel 的設計都是針對單機的，只能控制單機上多個進程間的訪問。 如果還依賴 OS Kernel 的服務，就無法保證多個主機間的協(xié)調(diào)工作。 這時就需要引入額外的控制機制，在RAC 中，這個機制就是位于 Oracle 和 OS Kernel 之間的 Clusterware，它會在 OS Kernel 之前截獲請求，然后和其他結點上的 Clusterware 協(xié)商，最終完成上層的請求。在 Oracle 10G 之前，RAC 所需要的集群件依賴與硬件廠商，比如 SUN,HP,Veritas. 從 Oracle 10.1版本中，Oracle推出了自己的集群產(chǎn)品. Cluster Ready Service(CRS),從此 RAC 不在依賴與任何廠商的集群軟件。 在 Oracle 10.2版本中，這個產(chǎn)品改名為：Oracle Clusterware。所以我們可以看出， 在整個 RAC 集群中，實際上有 2 個集群環(huán)境的存在，一個是由 Clusterware 軟件組成的集群，另一個是由 Database 組成的集群。
a) CRSD——負責集群的高可用操作，管理的 crs 資源包括數(shù)據(jù)庫、實例、監(jiān)聽、虛擬 IP，ons，gds 或者其他，操作包括啟動、關閉、監(jiān)控及故障切換。改進程由 root 用戶管理和啟動。crsd 如果有故障會導致系統(tǒng)重啟。
b) cssd，管理各節(jié)點的關系，用于節(jié)點間通信，節(jié)點在加入或離開集群時通知集群。該進程由 oracle 用戶運行管理。發(fā)生故障時 cssd 也會自動重啟系統(tǒng)。
c) oprocd – 集群進程管理 —Process monitor for the cluster. 用于保護共享數(shù)據(jù) IO fencing。
d) 僅在沒有使用 vendor 的集群軟件狀態(tài)下運行
e) evmd ：事件檢測進程，由 oracle 用戶運行管理
Cluster Ready Service（CRS，集群準備服務）是管理集群內(nèi)高可用操作的基本程序。Crs 管理的任何事物被稱之為資源，它們可以是一個數(shù)據(jù)庫、一個實例、一個監(jiān)聽、一個虛擬 IP（VIP）地址、一個應用進程等等。CRS是根據(jù)存儲于 OCR 中的資源配置信息來管理這些資源的。這包括啟動、關閉、監(jiān)控及故障切換（start、stop、monitor 及 failover）操作。當一資源的狀態(tài)改變時，CRS 進程生成一個事件。當你安裝 RAC 時，CRS 進程監(jiān)控Oracle 的實例、監(jiān)聽等等，并在故障發(fā)生時自動啟動這些組件。默認情況下，CRS 進程會進行 5 次重啟操作，如果資源仍然無法啟動則不再嘗試。Event Management（EVM）：發(fā)布 CRS 創(chuàng)建事件的后臺進程。Oracle Notification Service（ONS）：通信的快速應用通知（FAN：Fast Application Notification）事件的發(fā)布及訂閱服務。RACG：為 clusterware 進行功能擴展以支持 Oracle 的特定需求及復雜資源。它在 FAN 事件發(fā)生時執(zhí)行服務器端的調(diào)用腳本（server callout script）Process Monitor Daemon（OPROCD）：此進程被鎖定在內(nèi)存中，用于監(jiān)控集群（cluster）及提供 I/O 防護（I/Ofencing）。OPROCD 執(zhí)行它的檢查，停止運行，且如果喚醒超過它所希望的間隔時，OPROCD 重置處理器及重啟節(jié)點。一個 OPROCD 故障將導致 Clusterware 重啟節(jié)點。
Cluster Synchronization Service（CSS）：CSS 集群同步服務，管理集群配置，誰是成員、誰來、誰走，通知成員，是集群環(huán)境中進程間通信的基礎。同樣，CSS 也可以用于在單實例環(huán)境中處理 ASM 實例與常規(guī) RDBMS 實例之間的交互作用。在集群環(huán)境中，CSS 還提供了組服務，即關于在任意給定時間內(nèi)哪些節(jié)點和實例構成集群的動態(tài)信息，以及諸如節(jié)點的名稱和節(jié)點靜態(tài)信息（這些信息在節(jié)點被加入或者移除時被修改）。CSS 維護集群內(nèi)的基本鎖功能（盡管大多數(shù)鎖有 RDBMS 內(nèi)部的集成分布式鎖管理來維護）。除了執(zhí)行其他作業(yè)外，CSS 還負責在集群內(nèi)節(jié)點間維持一個心跳的程序，并監(jiān)控投票磁盤的 split-brain 故障。在安裝 clusterware 的最后階段，會要求在每個節(jié)點執(zhí)行 root.sh 腳本，這個腳本會在/etc/inittab 文件的最后把這 3 個進程加入啟動項，這樣以后每次系統(tǒng)啟動時，clusterware 也會自動啟動，其中 EVMD 和 CRSD 兩個進程如果出現(xiàn)異常，則系統(tǒng)會自動重啟這兩個進程，如果是 CSSD 進程異常，系統(tǒng)會立即重啟。
注意：
RAC 軟件結構可以分為四部分。
(一) Operation System-Dependent（OSD）
RAC 通過操作系統(tǒng)的相關軟件來訪問操作系統(tǒng)和一些與 Cluster 相關的服務進程。OSD 軟件可能由 Oracle 提供（windows 平臺）或由硬件廠商提供（unix 平臺）。OSD 包括三個自部分：
(二) Real Application Cluster Shard Disk Component
RAC 中這部分組件和單實例 Oracle 數(shù)據(jù)庫中的組件沒有什么區(qū)別。包括一個或者多個控制文件、一些列聯(lián)機重做日志文件、可選的歸檔日志文件、數(shù)據(jù)文件等。在 RAC 中使用服務器參數(shù)文件會簡化參數(shù)文件的管理，可以將全局參數(shù)和實例特定的參數(shù)存儲在同一個文件中。
(三) Real Application Cluster-Specific Daemon and Instance Processes包括以下部分：
(四) The Global Cache and Global Enqueue Service
全局緩存服務（GCS）和全局隊列服務（GES）是 RAC 的集成組件，用于協(xié)調(diào)對共享數(shù)據(jù)庫和數(shù)據(jù)庫內(nèi)的共享資源的同時訪問。 GCS 和 GES 包括以下特性：
健忘問題是由于每個節(jié)點都有配置信息的拷貝，修改節(jié)點的配置信息不同步引起的。Oracle 采用的解決方法就是把這個配置文件放在共享的存儲上，這個文件就是 OCR Disk。OCR 中保存整個集群的配置信息，配置信息以”Key-Value” 的形式保存其中。在 Oracle 10g 以前，這個文件叫作 Server Manageability Repository(SRVM). 在 Oracle 10g，這部分內(nèi)容被重新設計，并重名為 OCR.在 Oracle Clusterware 安裝的過程中，安裝程序會提示用戶指定 OCR 位置。并且用戶指定的這個位置會被記錄在/etc/oracle/ocr.Loc(LinuxSystem) 或者/var/opt/oracle/ocr.Loc(SolarisSystem)文件中。而在 Oracle 9i RAC 中，對等的是 srvConfig.Loc 文件。Oracle Clusterware 在啟動時會根據(jù)這里面的內(nèi)容從指定位置讀入 OCR 內(nèi)容。
(一) OCR key
整個 OCR 的信息是樹形結構，有 3 個大分支。分別是 SYSTEM,DATABASE 和 CRS。每個分支下面又有許多小分支。這些記錄的信息只能由 root 用戶修改。
(二) OCR process
Oracle Clusterware 在 OCR 中存放集群配置信息，故 OCR 的內(nèi)容非常的重要，所有對 OCR 的操作必須確保OCR 內(nèi)容完整性，所以在 ORACLE Clusterware 運行過程中，并不是所有結點都能操作 OCR Disk.在每個節(jié)點的內(nèi)存中都有一份 OCR 內(nèi)容的拷貝，這份拷貝叫作 OCR Cache。每個結點都有一個 OCR Process來讀寫 OCR Cache，但只有一個節(jié)點的 OCR process 能讀寫 OCR Disk 中的內(nèi)容，這個節(jié)點叫作 OCR Master 結點。這個節(jié)點的 OCR process 負責更新本地和其他結點的 OCR Cache 內(nèi)容。所有需要OCR 內(nèi)容的其他進程，比如OCSSD,EVM等都叫作Client Process，這些進程不會直接訪問OCR Cache，而是像 OCR Process發(fā)送請求，借助 OCR Process獲得內(nèi)容，如果想要修改 OCR 內(nèi)容，也要由該節(jié)點的 OCR Process像 Master node 的 OCR process 提交申請，由 Master OCR Process 完成物理讀寫，并同步所有節(jié)點 OCR Cache 中的內(nèi)容。
Voting Disk 這個文件主要用于記錄節(jié)點成員狀態(tài)，在出現(xiàn)腦裂時，決定那個 Partion 獲得控制權，其他的Partion 必須從集群中剔除。在安裝 Clusterware 時也會提示指定這個位置。安裝完成后可以通過如下命令來查看Voting Disk 位置。$Crsctl query css votedisk。
每個集群節(jié)點通過專用高速網(wǎng)絡連接到所有其他節(jié)點，這種專用高速網(wǎng)絡也稱為集群互聯(lián)或高速互聯(lián) (HSI)。Oracle 的 Cache Fusion 技術使用這種網(wǎng)絡將每個主機的物理內(nèi)存 (RAM) 有效地組合成一個高速緩存。 OracleCache Fusion 通過在專用網(wǎng)絡上傳輸某個 Oracle 實例高速緩存中存儲的數(shù)據(jù)允許其他任何實例訪問這些數(shù)據(jù)。它還通過在集群節(jié)點中傳輸鎖定和其他同步信息保持數(shù)據(jù)完整性和高速緩存一致性。專用網(wǎng)絡通常是用千兆以太網(wǎng)構建的，但是對于高容量的環(huán)境，很多廠商提供了專門為 Oracle RAC 設計的低延遲、高帶寬的專有解決方案。 Linux 還提供一種將多個物理 NIC 綁定為一個虛擬 NIC 的方法（此處不涉及）來增加帶寬和提高可用性。
為維持高可用性，為每個集群節(jié)點分配了一個虛擬 IP 地址 (VIP)。 如果主機發(fā)生故障，則可以將故障節(jié)點的 IP 地址重新分配給一個可用節(jié)點，從而允許應用程序通過相同的 IP 地址繼續(xù)訪問數(shù)據(jù)庫。
即虛擬 IP，Oracle 推薦客戶端連接時通過指定的虛擬 IP 連接，這也是 Oracle10g 新推出的一個特性。其本質(zhì)目的是為了實現(xiàn)應用的無停頓(雖然目前還是有點小問題，但離目標已經(jīng)非常接近)。用戶連接虛 IP，這個 IP并非綁定于網(wǎng)卡，而是由 oracle 進程管理，一旦某個用戶連接的虛 IP 所在實例宕機，oracle 會自動將該 IP 映射到狀態(tài)正常的實例，這樣就不會影響到用戶對數(shù)據(jù)庫的訪問，也無須用戶修改應用。Oracle 的 TAF 建立在 VIP 技術之上。IP 和 VIP 區(qū)別在與： IP 是利用 TCP 層超時， VIP 利用的是應用層的立即響應。VIP 它是浮動的 IP. 當一個節(jié)點出現(xiàn)問題時會自動的轉(zhuǎn)到另一個節(jié)點上。
透明應用故障轉(zhuǎn)移（Transport Application Failover，TAF）是 oracle 數(shù)據(jù)提供的一項，普遍應用于 RAC 環(huán)境中，當然也可以用于 Data Guard 和傳統(tǒng)的 HA 實現(xiàn)的主從熱備的環(huán)境中。TAF 中的 Transparent 和 Failover，點出了這個高可用特性的兩大特點：
但是，TAF 是完美的嗎？是不是使用了 TAF，應用就能真的無縫地進行切換呢？對應用和數(shù)據(jù)庫有沒有其他什么要求？要回答這些問題，我們需要全面地了解、掌握 TAF。我始終認為，要用好一個東西，首先得掌握這個東西背后的工作原理與機制。首先來看看 Failover。Failover 有兩種，一種是連接時 Failover，另一種則是運行時 Failover。前者的作用在于，應用（客戶端）在連接數(shù)據(jù)庫時，如果由于網(wǎng)絡、實例故障等原因，連接不上時，能夠連接數(shù)據(jù)庫中的其他實例。后者的作用在于，對于一個已經(jīng)在工作的會話（也就是連接已經(jīng)建立），如果這個會話的實例異常中止等，應用（客戶端）能夠連接到數(shù)據(jù)庫的其他實例（或備用庫）。
負載均衡（Load-Banlance）是指連接的負載均衡。RAC 的負載均衡主要指的是新會話連接到 RAC 數(shù)據(jù)庫時，根據(jù)服務器節(jié)點的 CPU 負載判定這個新的連接要連接到哪個節(jié)點進行工作。Oracle RAC 可以提供動態(tài)的數(shù)據(jù)服務，負載均衡分為兩種，一種是基于客戶端連接的，一種是基于服務器端的。
Oracle 的 TAF 建立在 VIP 的技術之上。IP 和 VIP 區(qū)別在于：IP 是利用 TCP 層超時，VIP 利用的是應用層的立即響應。VIP 是是浮動的 IP，當一個節(jié)點出現(xiàn)問題的時候，會自動的轉(zhuǎn)到另一個節(jié)點上。假設有一個兩節(jié)點的 RAC，正常運行時每個節(jié)點上都有一個 VIP，即 VIP1 和 VIP2。當節(jié)點 2 發(fā)生故障，比如異常關系。RAC 會做如下操作：
(一) CRS 在檢測到 rac2 節(jié)點異常后，會觸發(fā) Clusterware 重構，最后把 rac2 節(jié)點剔除集群，由節(jié)點 1 組成新的集群。
(二) RAC 的 Failover 機制會把節(jié)點 2 的 VIP 轉(zhuǎn)移到節(jié)點 1 上，這時節(jié)點 1 的 PUBLIC 網(wǎng)卡上就有 3 個 IP 地址：VIP1,VIP2, PUBLIC IP1。
(三) 用戶對 VIP2 的連接請求會被 IP 層路由轉(zhuǎn)到節(jié)點 1。
(四) 因為在節(jié)點 1 上有 VIP2 的地址，所有數(shù)據(jù)包會順利通過路由層，網(wǎng)絡層，傳輸層。
(五) 但是，節(jié)點 1 上只監(jiān)聽 VIP1 和 public IP1 的兩個 IP 地址。并沒有監(jiān)聽 VIP2，故應用層沒有對應的程序接收這個數(shù)據(jù)包，這個錯誤立即被捕獲。
(六) 客戶端能夠立即接收到這個錯誤，然后客戶端會重新發(fā)起向 VIP1 的連接請求。VIP 特點：
RAC 環(huán)境下有多個實例，每個實例都需要有自己的一套 Redo Log 文件來記錄日志。這套 Redo Log 就叫做 RedoThread，其實單實例下也是 Redo Thread，只是這個詞很少被提及，每個實例一套 Redo Thread 的設計就是為了避免資源競爭造成的性能瓶頸。Redo Thread 有兩種，一種是 Private，創(chuàng)建語法 alter database add logfile ......thread n；另一種是 public，創(chuàng)建語法：alter database add logfile......；RAC 中每個實例都要設置 thread 參數(shù)，該參數(shù)默認值為 0。如果設置了這個參數(shù)，則使用缺省值 0，啟動實例后選擇使用 Public Redo Thread，并且實例會用獨占的方式使用該 Redo Thread。RAC 中每個實例都需要一個 Redo Thread，每個 Redo Log Thread 至少需要兩個 Redo Log Group，每個 Log Group成員大小應該相等，沒組最好有 2 個以上成員，這些成員應放在不同的磁盤上，防止單點故障。
注意：在 RAC 環(huán)境下，Redo Log Group 是在整個數(shù)據(jù)庫級別進行編號，如果實例 1 有 1,2 兩個日志組，那么實例 2 的日志組編號就應該從 3 開始，不能使用 1,2 編號了。在 RAC 環(huán)境上，所有實例的聯(lián)機日志必須放在共享存儲上，因為如果某個節(jié)點異常關閉，剩下的節(jié)點要進行 crash recovery，執(zhí)行 crash recovery 的這個節(jié)點必須能夠訪問到故障節(jié)點的連接日志，只有把聯(lián)機日志放在共享存儲上才能滿足這個要求。
RAC 中的每個實例都會產(chǎn)生自己的歸檔日志，歸檔日志只有在執(zhí)行 Media Recovery 時才會用到，所以歸檔日志不必放在共享存儲上，每個實例可以在本地存放歸檔日志。但是如果在單個實例上進行備份歸檔日志或者進行 Media Recovery 操作，又要求在這個節(jié)點必須能夠訪問到所有實例的歸檔日志，在 RAC 幻境下，配置歸檔日志可以有多種選擇。
使用 NFS 的方式將日志直接歸檔到存儲，例如兩個節(jié)點，每個節(jié)點都有 2 個目錄，Arch1，Arch2 分別對應實例 1 和實例 2 產(chǎn)生的歸檔日志。每個實例都配置一個歸檔位置，歸檔到本地，然后通過 NFS 把對方的目錄掛到本地。
實例間歸檔（Cross Instance Archive）是上一種方式的變種，也是比較常見的一種配置方法。兩個節(jié)點都創(chuàng)建 2 個目錄 Arch1 和 Arch2 分別對應實例 1 和實例 2 產(chǎn)生的歸檔日志。每個實例都配置兩個歸檔位置。位置 1對應本地歸檔目錄，位置 2 對應另一個實例。
使用 ASM 將日志歸檔到共享存儲，只是通過 Oracle 提供的 ASM，把上面的復雜性隱藏了，但是原理都一樣。
Oracle Clusterware 的輔助診斷，只能從 log 和 trace 進行。 而且它的日志體系比較復雜。 alert.log：$ORA_CRS_HOME/log/hostname/alert.Log，這是首選的查看文件。
Clusterware 后臺進程日志
$ORA_CRS_HOME/log/hostname/crsd/crsd.Log$ORA_CRS_HOME/log/hostname/cssd/ocsd.Log$ORA_CRS_HOME/log/hostname/evmd/evmd.Log$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)生的日志就放在這個目錄下，還有 $ORACLE_HOME/log/hostname/client/ 和$ORACLE_HOME/log/hostname/racg 也有相關的日志。
掃碼關注鍍金池微信號
手機訂課，優(yōu)惠多多