概述：寫下本文件的初衷和動力，來源於上篇的《oracle基本操作手冊》。oracle基本操作手冊是作者研一假期對oracle基礎知識學習的彙總。然後形成體系的總結，一則進行回顧複習，另則便於查詢使用。本圖文文件亦源於此。閱讀Oracle RAC安裝與使用教程前，筆者先對這篇文章整體構思和形成進行梳理。由於閱讀者知識儲備層次不同，我將從Oracle RAC安裝前的準備與規劃開始進行整體介紹安裝部署Oracle RAC。始於唐博士指導，對資料庫叢集進行配置安裝，前後經歷2，3個月的摸索。中間遇到不少問題。此文件也將一一記錄整理。(本文原創/整理，轉載請標註原文出處:)

白寧超

2015年7月16日

目錄

RAC 工作原理和相關元件

      OracleRAC 是多個單例項在配置意義上的擴充套件，實現由兩個或者多個節點（例項）使用一個共同的共享資料庫（例如，一個數據庫同時安裝多個例項並開啟）。在這種情況下，每一個單獨的例項有它自己的 cpu 和實體記憶體，也有自己的 SGA 和後臺程序。和傳統的 oracle 例項相比，在系統全域性區（SYSTEM CLOBAL AREA,SGA）與後臺程序有著顯著的不同。最大的不同之處在於多了一個GRD,GRD記憶體塊主要是記錄此rac有多少個叢集資料庫與系統資源，同時也會記錄資料塊的相關資訊，因為在 rac 架構中，每個資料塊在每一個 SGA 中都有一份副本，而 rac 必須知道這些資料塊的位置，版本，分佈以及目前的狀態，這些資訊就存放在 GRD 中，但 GRD 只負責存放不負責管理，管理的責任則交給後臺程序 GCS 和 GES 來進行。Oracle 的多個例項訪問一個共同的共享資料庫。每個例項都有自己的 SGA、PGA 和後臺程序，這些後臺程序應該是熟悉的，因為在 RAC 配置中，每個例項將需要這些後臺程序執行支撐的。可以從以下幾個方面瞭解 RAC工作原理和執行機制。

(一) SCN

      SCN 是 Oracle 用來跟蹤資料庫內部變化發生先後順序的機制，可以把它想象成一個高精度的時鐘，每個 Redo日誌條目，Undo Data Block，Data Block 都會有 SCN 號。 Oracle 的Consistent-Read， Current-Read，Multiversion-Block 都是依賴 SCN 實現。在 RAC 中，有 GCS 負責全域性維護 SCN 的產生，預設用的是 Lamport SCN 生成演算法，該演算法大致原理是： 在所有節點間的通訊內容中都攜帶 SCN， 每個節點把接收到的 SCN 和本機的 SCN 對比，如果本機的 SCN 小，則調整本機的 SCN 和接收的一致，如果節點間通訊不多，還會主動地定期相互通報。 故即使節點處於 Idle 狀態，還是會有一些 Redo log 產生。 還有一個廣播演算法（Broadcast），這個演算法是在每個 Commit 操作之後，節點要想其他節點廣播 SCN，雖然這種方式會對系統造成一定的負載，但是確保每個節點在 Commit 之後都能立即檢視到 SCN.這兩種演算法各有優缺點，Lamport 雖然負載小，但是節點間會有延遲，廣播雖然有負載，但是沒有延遲。Oracle 10g RAC 預設選用的是 BroadCast 演算法，可以從 alert.log 日誌中看到相關資訊：Picked broadcast on commit scheme to generate SCNS

(二) RAC 的 GES/GCS 原理

       全域性佇列服務（GES）主要負責維護字典快取和庫快取的一致性。字典快取是例項的 SGA 內所儲存的對資料字典資訊的快取，用於高速訪問。由於該字典資訊儲存在記憶體中，因而在某個節點上對字典進行的修改（如DDL)必須立即被傳播至所有節點上的字典快取。GES 負責處理上述情況，並消除例項間出現的差異。處於同樣的原因，為了分析影響這些物件的 SQL 語句，資料庫內物件上的庫快取鎖會被去掉。這些鎖必須在例項間進行維護，而全域性佇列服務必須確保請求訪問相同物件的多個例項間不會出現死鎖。LMON、LCK 和 LMD 程序聯合工作來實現全域性佇列服務的功能。GES 是除了資料塊本身的維護和管理（由 GCS 完成）之外，在 RAC 環境中調節節點間其他資源的重要服務。為了保證叢集中的例項的同步，兩個虛擬服務將被實現：全域性排隊服務（GES），它負責控制對鎖的訪問。

       全域性記憶體服務（GCS)，控制對資料塊的訪問。GES 是 分散式鎖管理器(DLM)的擴充套件，它是這樣一個機制，可以用來管理 oracle 並行伺服器的鎖和資料塊。在一個群集環境中，你需要限制對資料庫資源的訪問，這些資源在單 instance 資料庫中被 latches 或者 locks 來保護。比如說，在資料庫字典記憶體中的物件都被隱性鎖所保護，而在庫快取記憶體中的物件在被引用的時候，必須被 pin 所保護。在 RAC 群集中，這些物件代表了被全域性鎖所保護的資源。GES 是一個完整的 RAC 元件，它負責和群集中的例項全域性鎖進行溝通，每個資源有一個主節點例項，這個例項記錄了它當前的狀態。而且，資源的當前的狀態也記錄在所有對這個資源有興趣的例項上。GCS,是另一個 RAC 元件，負責協調不同例項間對資料塊的訪問。對這些資料塊的訪問以及跟新都記錄在全域性目錄中（GRD）,這個全域性目錄是一個虛擬的記憶體結構，在所有的例項中使用擴張。每個塊都有一個master例項，這個例項負責對GSD的訪問進行管理，GSD裡記錄了這個塊的當前狀態資訊。GCS 是 oracle 用來實施 Cache fusion 的機制。被 GCS 和 GES 管理的塊和鎖叫做資源。對這些資源的訪問必須在群集的多個例項中進行協調。這個協調在例項層面和資料庫層面都有發生。例項層次的資源協調叫做本地資源協調；資料庫層次的協調叫做全域性資源協調。

      本地資源協調的機制和單例項 oracle 的資源協調機制類似，包含有塊級別的訪問，空間管理，dictionary cache、library cache 管理，行級鎖，SCN 發生。全域性資源協調是針對 RAC 的，使用了 SGA 中額外的記憶體元件、演算法和後臺程序。GCS 和 GES 從設計上就是在對應用透明的情況下設計的。換一句話來說，你不需要因為資料庫是在 RAC上執行而修改應用,在單例項的資料庫上的並行機制在 RAC 上也是可靠地。

支援 GCS 和 GES 的後臺程序使用私網心跳來做例項之間的通訊。這個網路也被 Oracle 的 群集元件使用，也有可能被 群集檔案系統（比如 OCFS)所使用。GCS 和 GES 獨立於 Oracle 群集元件而執行。但是，GCS 和GES 依靠 這些群集元件獲得群集中每個例項的狀態。如果這些資訊不能從某個例項獲得，這個例項將被關閉。這個關閉操作的目的是保護資料庫的完整性，因為每個例項需要知道其他例項的情況，這樣可以更好的確定對資料庫的協調訪問。GES 控制資料庫中所有的 library cache 鎖和 dictionary cache 鎖。這些資源在單例項資料庫中是本地性的，但是到了 RAC 群集中變成了全域性資源。全域性鎖也被用來保護資料的結構，進行事務的管理。一般說來，事務和表鎖 在 RAC 環境或是 單例項環境中是一致的。

       Oracle 的各個層次使用相同的 GES 功能來獲得，轉化以及釋放資源。在資料庫啟動的時候，全域性佇列的個數將被自動計算。GES 使用後臺程序 LMD0 和 LCK0 來執行它的絕大多數活動。一般來說，各種程序和本地的 LMD0 後臺程序溝通來管理全域性資源。本地的 LMD0 後臺程序與 別的例項上的 LMD0 程序進行溝通。

      LCK0 後臺程序用來獲得整個例項需要的鎖。比如，LCK0 程序負責維護 dictionary cache 鎖。影子程序(服務程序） 與這些後臺程序通過 AST(非同步陷阱）訊息來通訊。非同步訊息被用來避免後臺程序的阻塞，這些後臺程序在等待遠端例項的的回覆的時候將阻塞。後臺程序也能 傳送 BAST(非同步鎖陷阱）來鎖定程序，這樣可以要求這些程序把當前的持有鎖置為較低階限制的模式。資源是記憶體結構，這些結構代表了資料庫中的元件，對這些元件的訪問必須為限制模式或者序列化模式。換一句話說，這個資源只能被一個程序或者一直例項並行訪問。如果這個資源當前是處於使用狀態，其他想訪問這個資源的程序必須在佇列中等待，直到資源變得可用。佇列是記憶體結構，它負責並行化對特殊資源的訪問。如果這些資源只被本地例項需求，那麼這個佇列可以本地來獲得，而且不需要協同。但是如果這個資源被遠端例項所請求，那麼本地佇列必須變成全球化。

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 組成的叢集。

(一) Clusterware 的主要程序

a) CRSD——負責叢集的高可用操作，管理的 crs 資源包括資料庫、例項、監聽、虛擬 IP，ons，gds 或者其他，操作包括啟動、關閉、監控及故障切換。改程序由 root 使用者管理和啟動。crsd 如果有故障會導致系統重啟。

b) cssd，管理各節點的關係，用於節點間通訊，節點在加入或離開叢集時通知叢集。該程序由 oracle 使用者執行管理。發生故障時 cssd 也會自動重啟系統。

c) oprocd – 叢集程序管理 —Process monitor for the cluster. 用於保護共享資料 IO fencing。

d) 僅在沒有使用 vendor 的叢集軟體狀態下執行

e) evmd ：事件檢測程序，由 oracle 使用者執行管理

      Cluster Ready Service（CRS，叢集準備服務）是管理叢集內高可用操作的基本程式。Crs 管理的任何事物被稱之為資源，它們可以是一個數據庫、一個例項、一個監聽、一個虛擬 IP（VIP）地址、一個應用程序等等。CRS是根據儲存於 OCR 中的資源配置資訊來管理這些資源的。這包括啟動、關閉、監控及故障切換（start、stop、monitor 及 failover）操作。當一資源的狀態改變時，CRS 程序生成一個事件。當你安裝 RAC 時，CRS 程序監控Oracle 的例項、監聽等等，並在故障發生時自動啟動這些元件。預設情況下，CRS 程序會進行 5 次重啟操作，如果資源仍然無法啟動則不再嘗試。Event Management（EVM）：釋出 CRS 建立事件的後臺程序。Oracle Notification Service（ONS）：通訊的快速應用通知（FAN：Fast Application Notification）事件的釋出及訂閱服務。RACG：為 clusterware 進行功能擴充套件以支援 Oracle 的特定需求及複雜資源。它在 FAN 事件發生時執行伺服器端的呼叫指令碼（server callout script）Process Monitor Daemon（OPROCD）：此程序被鎖定在記憶體中，用於監控叢集（cluster）及提供 I/O 防護（I/Ofencing）。OPROCD 執行它的檢查，停止執行，且如果喚醒超過它所希望的間隔時，OPROCD 重置處理器及重啟節點。一個 OPROCD 故障將導致 Clusterware 重啟節點。

      Cluster Synchronization Service（CSS）：CSS 叢集同步服務，管理叢集配置，誰是成員、誰來、誰走，通知成員，是叢集環境中程序間通訊的基礎。同樣，CSS 也可以用於在單例項環境中處理 ASM 例項與常規 RDBMS 例項之間的互動作用。在叢集環境中，CSS 還提供了組服務，即關於在任意給定時間內哪些節點和例項構成叢集的動態資訊，以及諸如節點的名稱和節點靜態資訊（這些資訊在節點被加入或者移除時被修改）。CSS 維護叢集內的基本鎖功能（儘管大多數鎖有 RDBMS 內部的整合分散式鎖管理來維護）。除了執行其他作業外，CSS 還負責在叢集內節點間維持一個心跳的程式，並監控投票磁碟的 split-brain 故障。在安裝 clusterware 的最後階段，會要求在每個節點執行 root.sh 指令碼，這個指令碼會在/etc/inittab 檔案的最後把這 3 個程序加入啟動項，這樣以後每次系統啟動時，clusterware 也會自動啟動，其中 EVMD 和 CRSD 兩個程序如果出現異常，則系統會自動重啟這兩個程序，如果是 CSSD 程序異常，系統會立即重啟。

注意：

1、Voting Disk 和 OCR 必須儲存在儲存裝置上供各個節點訪問。

2、Voting Disk、OCR 和網路是安裝的過程中或者安裝前必須要指定或者配置的。安裝完成後可以通過一些工具進行配置和修改。

RAC 軟體結構

RAC 軟體結構可以分為四部分。

1. 作業系統相關的軟體
2. RAC 共享磁碟部分
3. RAC 中特別的後臺程序和例項程序
4. 全域性緩衝區服務和全域性佇列服務

(一) Operation System-Dependent（OSD）

     RAC 通過作業系統的相關軟體來訪問作業系統和一些與 Cluster 相關的服務程序。OSD 軟體可能由 Oracle 提供（windows 平臺）或由硬體廠商提供（unix 平臺）。OSD 包括三個自部分：

• l  The Cluster Manager(CM)：叢集監視器監視節點間通訊，並通過 interconnect 來協調節點操作。同時還提供 CLUSTER 中所有節點和例項的統一檢視。CM 還控制 CLUSTER 的成員資格。
• l  The Node Monitor（節點監視器）：節點監視器提供節點內各種資源的狀態，包括節點、interconnect 硬體和軟體和共享磁碟等。
• l  The Interconnect 節點間心跳（兩種心跳機制，一種是通過私有網路的 network heartbeat；另一種是通過 voting disk 的 disk heartbeat）

(二) Real Application Cluster Shard Disk Component

       RAC 中這部分元件和單例項 Oracle 資料庫中的元件沒有什麼區別。包括一個或者多個控制檔案、一些列聯機重做日誌檔案、可選的歸檔日誌檔案、資料檔案等。在 RAC 中使用伺服器引數檔案會簡化引數檔案的管理，可以將全域性引數和例項特定的引數儲存在同一個檔案中。

(三) Real Application Cluster-Specific Daemon and Instance Processes包括以下部分：

1. The Global Service Daemon（GSD）：在每個節點上都執行一個全域性服務後臺程序，用於接收客戶端如DBCA、EM 等發出的管理訊息，並完成相應的管理任務，比如例項的啟動和關閉。
2. RAC 中特別的例項程序： Global Cache Service Processes(LMSn)：控制到遠端例項的訊息的流量，管理全域性資料塊的訪問。還用於在不同例項的緩衝區之間傳遞 BLOCK 的對映。
3. Global Enqueue Service Monitor(LMON)：監視全域性佇列和叢集間的資源互動，執行全域性佇列的恢復操作。
4.  Global Enqueue Service Daemon(LMD)：管理全域性佇列和全域性資源訪問。對於每個例項，LMD 管理來自遠端的資源請求。
5. Lock Processes(LCK)：管理除 Cache Fusion 以外的非資料塊資源請求，比如資料檔案，控制檔案，資料字典試圖，library 和 row cache 的請求。
6. Diagnosability Daemon(DIAG)：在例項中捕獲程序失敗的診斷資料。

(四) The Global Cache and Global Enqueue Service

全域性快取服務（GCS）和全域性佇列服務（GES）是 RAC 的整合元件，用於協調對共享資料庫和資料庫內的共享資源的同時訪問。

GCS 和 GES 包括以下特性：

1. 應用透明性。
2. 分散式結構
3. 分散式結構的全域性資源目錄：只要還存在一個節點，即使出現一個或多個節點失敗，GCS 和 GES 仍然可以保證全域性資源目錄的完整性。
4. 資源控制：GCS 和 GES 會選擇一個例項來管理所有的資源資訊，這個例項叫做 resource master。GCS和 GES 會根據資料訪問方式階段性的評估和修改 resource master。這種方式會減少網路流量和資源獲取時間。
5.  GCS 和 GES 與 CM 之間的互動：GCS 和 GES 獨立於 CM。但同時 GCS 和 GES 依賴於 CM 提供的各個節點上例項的狀態資訊。一旦無法取得某個例項的資訊，則 Oracle 會馬上關閉沒有響應的例項，來保證整個 RAC 的完整性。

叢集註冊（OCR）

        健忘問題是由於每個節點都有配置資訊的拷貝，修改節點的配置資訊不同步引起的。Oracle 採用的解決方法就是把這個配置檔案放在共享的儲存上，這個檔案就是 OCR Disk。OCR 中儲存整個叢集的配置資訊，配置資訊以”Key-Value” 的形式儲存其中。在 Oracle 10g 以前，這個檔案叫作 Server Manageability Repository(SRVM). 在 Oracle 10g，這部分內容被重新設計，並重名為 OCR.在 Oracle Clusterware 安裝的過程中，安裝程式會提示使用者指定 OCR 位置。並且使用者指定的這個位置會被記錄在/etc/oracle/ocr.Loc(LinuxSystem) 或者/var/opt/oracle/ocr.Loc(SolarisSystem)檔案中。而在 Oracle 9i RAC 中，對等的是 srvConfig.Loc 檔案。Oracle Clusterware 在啟動時會根據這裡面的內容從指定位置讀入 OCR 內容。

(一) OCR key

整個 OCR 的資訊是樹形結構，有 3 個大分支。分別是 SYSTEM,DATABASE 和 CRS。每個分支下面又有許多小分支。這些記錄的資訊只能由 root 使用者修改。

(二) 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 中的內容。

Oracle 仲裁盤（Voting Disk）

      Voting Disk 這個檔案主要用於記錄節點成員狀態，在出現腦裂時，決定那個 Partion 獲得控制權，其他的Partion 必須從叢集中剔除。在安裝 Clusterware 時也會提示指定這個位置。安裝完成後可以通過如下命令來檢視Voting Disk 位置。$Crsctl query css votedisk

叢集的網路連線

一、專用網路

      每個叢集節點通過專用高速網路連線到所有其他節點，這種專用高速網路也稱為叢集互聯或高速互聯 (HSI)。Oracle 的 Cache Fusion 技術使用這種網路將每個主機的實體記憶體 (RAM) 有效地組合成一個快取記憶體。 OracleCache Fusion 通過在專用網路上傳輸某個 Oracle 例項快取記憶體中儲存的資料允許其他任何例項訪問這些資料。它還通過在叢集節點中傳輸鎖定和其他同步資訊保持資料完整性和快取記憶體一致性。專用網路通常是用千兆乙太網構建的，但是對於高容量的環境，很多廠商提供了專門為 Oracle RAC 設計的低延遲、高頻寬的專有解決方案。 Linux 還提供一種將多個物理 NIC 繫結為一個虛擬 NIC 的方法（此處不涉及）來增加頻寬和提高可用性。

二、公共網路

     為維持高可用性，為每個叢集節點分配了一個虛擬 IP 地址 (VIP)。 如果主機發生故障，則可以將故障節點的 IP 地址重新分配給一個可用節點，從而允許應用程式通過相同的 IP 地址繼續訪問資料庫。

三、Virtual lP（VIP）

      即虛擬 IP，Oracle 推薦客戶端連線時通過指定的虛擬 IP 連線，這也是 Oracle10g 新推出的一個特性。其本質目的是為了實現應用的無停頓(雖然目前還是有點小問題，但離目標已經非常接近)。使用者連線虛 IP，這個 IP並非綁定於網絡卡，而是由 oracle 程序管理，一旦某個使用者連線的虛 IP 所在例項宕機，oracle 會自動將該 IP 對映到狀態正常的例項，這樣就不會影響到使用者對資料庫的訪問，也無須使用者修改應用。Oracle 的 TAF 建立在 VIP 技術之上。IP 和 VIP 區別在與： IP 是利用 TCP 層超時， VIP 利用的是應用層的立即響應。VIP 它是浮動的 IP. 當一個節點出現問題時會自動的轉到另一個節點上。

透明應用切換（TAF）

透明應用故障轉移（Transport Application Failover，TAF）是 oracle 資料提供的一項，普遍應用於 RAC 環境中，當然也可以用於 Data Guard 和傳統的 HA 實現的主從熱備的環境中。TAF 中的 Transparent 和 Failover，點出了這個高可用特性的兩大特點：

1. TAF 是用於故障轉移的，也就是切換。當 Oracle 連線的會話由於資料庫發生故障不可用時，會話能夠自動切換到 RAC 中的其他可用的節點上，或者切換到 Standby 上面，或者切換到 HA 方式中的另一個可用的節點上面。
2. TAF 的故障轉移，對應用來說是透明的，應用系統不需要進行特別的處理就能夠自動進行故障轉移。

但是，TAF 是完美的嗎？是不是使用了 TAF，應用就能真的無縫地進行切換呢？對應用和資料庫有沒有其他什麼要求？要回答這些問題，我們需要全面地瞭解、掌握 TAF。我始終認為，要用好一個東西，首先得掌握這個東西背後的工作原理與機制。首先來看看 Failover。Failover 有兩種，一種是連線時 Failover，另一種則是執行時 Failover。前者的作用在於，應用（客戶端）在連線資料庫時，如果由於網路、例項故障等原因，連線不上時，能夠連線資料庫中的其他例項。後者的作用在於，對於一個已經在工作的會話（也就是連線已經建立），如果這個會話的例項異常中止等，應用（客戶端）能夠連線到資料庫的其他例項（或備用庫）。

連線負載均衡

      負載均衡（Load-Banlance）是指連線的負載均衡。RAC 的負載均衡主要指的是新會話連線到 RAC 資料庫時，根據伺服器節點的 CPU 負載判定這個新的連線要連線到哪個節點進行工作。Oracle RAC 可以提供動態的資料服務，負載均衡分為兩種，一種是基於客戶端連線的，一種是基於伺服器端的。

VIP 的原理和特點

       Oracle 的 TAF 建立在 VIP 的技術之上。IP 和 VIP 區別在於：IP 是利用 TCP 層超時，VIP 利用的是應用層的立即響應。VIP 是是浮動的 IP，當一個節點出現問題的時候，會自動的轉到另一個節點上。假設有一個兩節點的 RAC，正常執行時每個節點上都有一個 VIP，即 VIP1 和 VIP2。當節點 2 發生故障，比如異常關係。RAC 會做如下操作：

(一) CRS 在檢測到 rac2 節點異常後，會觸發 Clusterware 重構，最後把 rac2 節點剔除叢集，由節點 1 組成新的叢集。

(二) RAC 的 Failover 機制會把節點 2 的 VIP 轉移到節點 1 上，這時節點 1 的 PUBLIC 網絡卡上就有 3 個 IP 地址：VIP1,VIP2, PUBLIC IP1.

(三) 使用者對 VIP2 的連線請求會被 IP 層路由轉到節點 1

(四) 因為在節點 1 上有 VIP2 的地址，所有資料包會順利通過路由層，網路層，傳輸層。

(五) 但是，節點 1 上只監聽 VIP1 和 public IP1 的兩個 IP 地址。並沒有監聽 VIP2，故應用層沒有對應的程式接收這個資料包，這個錯誤立即被捕獲。

(六) 客戶端能夠立即接收到這個錯誤，然後客戶端會重新發起向 VIP1 的連線請求。VIP 特點：

• l   VIP 是通過 VIPCA 指令碼建立的。
• l   VIP 作為 Nodeapps 型別的 CRS Resource 註冊到 OCR 中，並由 CRS 維護狀態。
• l   VIP 會繫結到節點的 public 網絡卡上，故 public 網絡卡有 2 個地址。
• l   當某個節點發生故障時，CRS 會把故障節點的 VIP 轉移到其他節點上。
• l   每個節點的 Listener 會同時監聽 public 網絡卡上的 public ip 和 VIP.
• l   客戶端的 tnsnames.Ora 一般會配置指向節點的 VIP.

日誌體系

Redo Thread

       RAC 環境下有多個例項，每個例項都需要有自己的一套 Redo Log 檔案來記錄日誌。這套 Redo Log 就叫做 RedoThread，其實單例項下也是 Redo Thread，只是這個詞很少被提及，每個例項一套 Redo Thread 的設計就是為了避免資源競爭造成的效能瓶頸。Redo Thread 有兩種，一種是 Private，建立語法 alter database add logfile ......thread n；另一種是 public，建立語法：alter database add logfile......；RAC 中每個例項都要設定 thread 引數，該引數預設值為 0。如果設定了這個引數，則使用預設值 0，啟動例項後選擇使用 Public Redo Thread，並且例項會用獨佔的方式使用該 Redo Thread。RAC 中每個例項都需要一個 Redo Thread，每個 Redo Log Thread 至少需要兩個 Redo Log Group，每個 Log Group成員大小應該相等，沒組最好有 2 個以上成員，這些成員應放在不同的磁碟上，防止單點故障。

注意：在 RAC 環境下，Redo Log Group 是在整個資料庫級別進行編號，如果例項 1 有 1,2 兩個日誌組，那麼例項 2 的日誌組編號就應該從 3 開始，不能使用 1,2 編號了。在 RAC 環境上，所有例項的聯機日誌必須放在共享儲存上，因為如果某個節點異常關閉，剩下的節點要進行 crash recovery，執行 crash recovery 的這個節點必須能夠訪問到故障節點的連線日誌，只有把聯機日誌放在共享儲存上才能滿足這個要求。

Archive log

      RAC 中的每個例項都會產生自己的歸檔日誌，歸檔日誌只有在執行 Media Recovery 時才會用到，所以歸檔日誌不必放在共享儲存上，每個例項可以在本地存放歸檔日誌。但是如果在單個例項上進行備份歸檔日誌或者進行 Media Recovery 操作，又要求在這個節點必須能夠訪問到所有例項的歸檔日誌，在 RAC 幻境下，配置歸檔日誌可以有多種選擇。

1. 使用 NFS

使用 NFS 的方式將日誌直接歸檔到儲存，例如兩個節點，每個節點都有 2 個目錄，Arch1，Arch2 分別對應例項 1 和例項 2 產生的歸檔日誌。每個例項都配置一個歸檔位置，歸檔到本地，然後通過 NFS 把對方的目錄掛到本地。

1. 例項間歸檔（Cross Instance Archive CIA）

例項間歸檔（Cross Instance Archive）是上一種方式的變種，也是比較常見的一種配置方法。兩個節點都建立 2 個目錄 Arch1 和 Arch2 分別對應例項 1 和例項 2 產生的歸檔日誌。每個例項都配置兩個歸檔位置。位置 1對應本地歸檔目錄，位置 2 對應另一個例項

1. 使用 ASM

使用 ASM 將日誌歸檔到共享儲存，只是通過 Oracle 提供的 ASM，把上面的複雜性隱藏了，但是原理都一樣。

Trace 日誌

Oracle Clusterware 的輔助診斷，只能從 log 和 trace 進行。 而且它的日誌體系比較複雜。 alert.log：$ORA_CRS_HOME/log/hostname/alert.Log, 這是首選的檢視檔案。

Clusterware 後臺程序日誌

• l  crsd.Log: $ORA_CRS_HOME/log/hostname/crsd/crsd.Log
• l  ocssd.Log: $ORA_CRS_HOME/log/hostname/cssd/ocsd.Log
• l  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 也有相關的日誌。

參考文獻

相關文章