【RAC】RAC相關基礎知識

 

【RAC】RAC相關基礎知識

---

---

1.CRS簡介

   從Oracle 10G開始，oracle引進一套完整的集羣管理解決方案—-Cluster-Ready Services，它包括集羣連通性.消息和鎖.負載管理等框架.從而使得RAC能夠脫離第三方集羣件，固然，CRS與第三方集羣件能夠共同使用.

(1).CRS進程

CRS主要由三部分組成，三部分都做爲守護進程出現

<1>CRSD：資源可用性維護的主要引擎.它用來執行高可用性恢復及管理操做，諸如維護OCR及管理應用資源，它保存着集羣的信息狀態和OCR的配置，此進程以root權限運行.

<2>EVMD：事件管理守護進程.此進程還負責啓動racgevt進程以管理FAN服務器端調用，此進程以root權限運行

<3>OCSSD：集羣同步服務進程.管理集羣節點的成員資格，它以fatal方式啓動，所以進程發生故障將致使集羣重啓，以防止數據壞死.同時，CSS還維護集羣內的基本鎖功能，以及負責監控voting disk的腦裂故障。它以Oracle權限運行

此外，還有一個進程OPRCD，他是集羣中的進程監視程序，僅當平臺上的CRS不使用廠商羣件時候纔出現，且不管運行了多少實例，每一個節點只會存在一組後臺進程.

來看一下這幾個守護進程: 

rac1-> cat/etc/inittab

…………………………….

# Run xdm in runlevel 5

x:5:respawn:/etc/X11/prefdm –nodaemon

h1:35:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1 </dev/null

h2:35:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1 </dev/null

h3:35:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1 </dev/null

 

  (2).Virtual IP Address

Oracle 10G RAC下，有3個重要的IP.

① Public IP  ② Private IP  ③ Vitual IP

Public IP爲數據庫所在主機的公共網絡IP，Private IP被用來私有高速互聯，而Oracle較前版本，增長了一個虛擬IP，用來節點發生故障時候更快的故障轉移，oracle利用每一個節點的lisnter偵聽VIP，一旦發生故障，VIP將進行實際的故障切換，從而在其餘的可用的節點上保持聯機，從而下降客戶應用程序意識到節點故障所須要的時間。

VIP與Public IP必須在同一個網段內。

(3).OCR，Voting disk
      OCR(oracle集羣註冊表)和Voting disk(表決磁盤)是CRS下的兩個重要組件，它們必須放在共享磁盤上，以保證每一個節點都能對其訪問。

OCR包含了針對集羣的一些配置信息，諸如:集羣數據庫中的節點列表.CRS應用程序.資源文件以及事件管理器的受權信息。他負責對集羣內的資源追蹤，從而獲知資源正在哪裏運行，應該能夠在哪裏運行。

Voting disk用來解決split-brain故障:若是節點丟失了與集羣中其餘節點的網絡鏈接，這些衝突由表決磁盤中的信息來解決

2.ASM相關 

ASM (Automated Storage Management) 是Oracle 10G引入的一種文件類型，他提供了直接的I/O讀寫，是RAC體系下一套不錯的對數據文件存儲規劃的方案. ASM能夠自動管理磁盤組，並提供數據冗餘和優化.後面章節會就ASM的管理以及ASM下的RAC管理，單獨講解.

3.RAC存儲/網絡需求

 

(1).存儲需求

共享存儲器是RAC的重要組件之一。它要求集羣內的節點能夠同時讀寫物理磁盤。目前，支持共享存儲的文件類型也比較多，像Oracle自身提供的ASM，OCFS2以及三方提供的羣集文件系統，都是能夠選擇的類型。

表1.1.1顯示了RAC 體系架構下各部分所支持的存儲類型 (暫不考慮三方集羣文件系統，就ASM/raw device/OCFS2和普通文件系統來講)

表1.1.1  RAC各部分所支持的存儲類型

類別	支持的存儲類型	存儲位置	備註
Cluster 軟件	OCFS2，普通文件系統	共享磁盤/本地磁盤
OCR，Voting disk	OCFS2，raw device	共享磁盤
數據庫軟件	OCFS2，普通文件系統	共享磁盤/本地磁盤
數據庫文件	OCFS2，raw device，ASM	共享磁盤
歸檔日誌文件	OCFS2，ASM，普通文件系統	共享磁盤/本地磁盤
備份/恢復文件	OCFS2，ASM，普通文件系統	共享磁盤/本地磁盤
閃回日誌文件	OCFS2，ASM	共享磁盤

(2).網絡需求

  每一個節點主機上至少須要2張物理網卡，以便分配公有IP和私有IP地址。對於私有IP鏈接，每一個集羣節點經過專用高速網絡鏈接到全部其餘節點，目的在於集羣上的節點和實例交換信息狀態（鎖信息，全局緩存信息等）。經過高速互聯，Cache Fusion得以實現。

  在實際環境中，高速互聯至少須要配置GB級的以太網，並且，最好不要使用交叉直連。

較好的解決方案是節點間配置專用交換機，這樣避免由於集羣上一個節點宕掉而影響另外節點的正常工做。

4.其餘

(1).後臺進程

 

圖1.4.1 Backgroud Process in RAC 10g

      因爲要維護多個實例同時訪問資源所必需的鎖定，所以，同single instance相比，RAC下增長了額外的一些進程。專門針對RAC的進程有以下幾種：

1.  LMS(Global Cache Service)  全局緩存服務進程

     LMS負責爲緩存融合請求在實例間傳遞塊。當一致性請求的時候，LMS首先回滾塊，建立塊的讀一致性映像（CR），而後將該一致性版本經過高速互聯傳遞處處理此請求的遠程實例中的前臺進程上，LMS進程保證了在同一時刻只容許一個實例去更新數據塊。

     LMS進程的數量由初始化參數GCS_SERVER_PROCESSES控制。Oracle最大支持36個LMS進程（0–9 and a–z），該初始化參數默認值爲2。

2.  LMD (Global Enqueue Service Daemon) 全局隊列服務守護進程

     LMD負責管理全局隊列和全局資源訪問，並更新相應隊列的狀態，此外還負責遠程節點資源的請求與死鎖的檢測。LMD與LMS進程互交工做，共同維護GRD。

3.  LMON (Global Enqueue Service Monitor) 全局隊列服務監控器進程

     LMON是全局隊列服務的監控器，他負責檢查集羣內實例的死亡狀況併發起從新配置，當實例加入或者離開集羣的時候，它負責從新配置鎖和資源。

4.  LCK(Lock process) 鎖進程

     LCK管理那些不是緩存融合的請求，例如library cahe, row cache.因爲LMS進程提供了主要的鎖管理功能，所以每一個節點實例上只有一個LCK進程。

DIAG (The Diagnostic Daemon）診斷守護進程

     DIAG負責監控實例的健康情況並捕獲進程失敗的信息，並將失敗信息寫入用於失敗分析，該進程自動啓動且不須要人爲調整，若失敗則自動從新啓動。

(2).緩存融合/緩存一致性

      Cache Fusion是RAC工做原理的一箇中心環節.他的本質就是經過互聯網絡在集羣內各節點的SGA之間進行塊傳遞，從而避免了首先將塊推送到磁盤，而後再從新讀入其餘實例的緩存中，從而最大限度的減小I/O。當一個塊被讀入RAC環境中某個實例的緩存時，該塊會被賦予一個鎖資源（與行級鎖不一樣），以確保其餘實例知道該塊正在被使用。以後，若是另外一個實例請求該塊的一個拷貝，而該塊已經處於前一個實例的緩存內，那麼該塊會經過互聯網絡直接被傳遞到另外一個實例的SGA。若是內存中的塊已經被改變，但改變還沒有提交，那麼將會傳遞一個CR副本。這就意味着，只要可能，數據塊無需寫回磁盤便可在各實例緩存之間移動，從而避免了同步多實例的緩存所花費的額外I/O，由此，須要互聯網絡的速度是高速的，須要快於磁盤訪問的速度．

      GCS負責維護全局緩衝區內的緩存一致性，LMS進程是其主要組成部分。GCS確保同一時刻某個塊上，只能有來自一個實例上的進程能對其修改,同時，並得到該塊的當前版本和前映像，以及塊所處的狀態（NULL,,Shared, Exclusive），模式(local/gobal)。

     GES負責維護dictionary cache和library cache緩存一致性（這個與LCK是不一樣的）。因爲存在某個節點上對數據字典的修改(好比ddl和dcl對object屬性的修改)，GES負責同步各節點上的字典緩存,消除差別。GES確保請求訪問相同對象的多個實例間不會出現死鎖。

     GRD包含了全部共享資源的當前狀態信息，它由GES和GCS共同維護，GRD貯存在內存中，被用來管理全局資源活動。好比：當一個實例第一次讀取某塊到SGA的時候，該塊的角色爲LOCAL，GCS記錄此狀態到GRD，一旦有另外的實例請求該塊，GCS會更新GRD，將此塊的角色由LOCAL變爲GLOBAL。

二 RAC安裝

不用把安裝RAC當作是多麼困難的一件事情.足夠細心和耐性，充分的準備工做，而後加上一丁點運氣，相信你能很快部署好一個RAC測試環境.固然，虛擬環境和實際環境的安裝不盡相同，並且，生產系統環境的搭建須要通過縝密的規劃和系統的測試.但大同小異，安裝過程不應稱爲咱們的絆腳石.

1.安裝規劃部署

安裝以前需重點規劃RAC系統各文件的存儲類型.能夠參見表1.3.1。一個好的存儲規劃方案，能夠省去不少後續的維護成本。

2. 安裝過程

安裝過程能夠參考oracle聯機文檔install guid。(Vmware安裝能夠參考Vincent Chan發表在oracle網站上的一文<使用 VMware Server 在 Oracle Enterprise Linux 上安裝 Oracle RAC 10g>.文中講的很詳細，在此簡單帶過.)。簡單列一下安裝RAC的幾個重要步驟

配置系統內核參數以及環境

配置共享存儲

安裝CRS軟件

安裝RDBMS軟件

建立數據庫以及配置其餘

3.幾點注意問題.

特別提一下vmware下的時間同步問題，在個人環境下，兩節點上時間差異很大.一開始採用vmware-toolbox工具同步宿主時間，效果不理想.能夠在每一個節點上放置一個小腳本，讓他每隔一段時間以另外一個節點爲基準同步時間.這樣，時間同步問題迎刃而解.在個人環境下，我設置每20秒同步一次時間.

rac1>cat date.sh

#!/bin/sh

while true

do

rdate -s rac2>dev/null 2>&1

sleep 10

done

三 RAC管理維護

同Single instance相比，RAC的管理維護要複雜一些。10g給咱們提供了一個強大的EM管理工具，將不少管理維護工做簡單和界面化。咱們也應當習慣使用EM來高效的完成更多的工做。本文如下部分，將暫不討論EM方面的管理，着重於命令行方式。

1.CRS管理維護

(1).CRS相關的接口命令

CRS在10G RAC體系下有着舉足輕重的做用。Oracle也提供了一些命令接口讓咱們診斷維護它。

<1>CRS_*

10G RAC下，有這麼幾組crs_命令維護CRS資源。

 

[root@rac2 bin]# ls $ORA_CRS_HOME/bin|grep "crs_"|grep -v bin
crs_getperm  crs_profile  crs_register  crs_relocate  crs_setperm  crs_start  crs_stat  crs_stop  crs_unregister

下面分別講述一下它們。

集羣資源查詢：CRS_STAT

能夠用來查看RAC中各節點上resources的運行情況,Resources的屬性等。

例如使用－t選項，檢查資源狀態：

[root@rac1 ~]# crs_stat –t

Name Type Target State Host

ora.demo.db application ONLINE ONLINE rac2

ora....o1.inst application ONLINE ONLINE rac1

ora....o2.inst application ONLINE ONLINE rac2

ora....SM1.asm application ONLINE ONLINE rac1

ora....C1.lsnr application ONLINE ONLINE rac1
ora.rac1.gsd application ONLINE ONLINE rac1

ora.rac1.ons application ONLINE ONLINE rac1

ora.rac1.vip application ONLINE ONLINE rac1

ora....SM2.asm application ONLINE ONLINE rac2

ora....C2.lsnr application ONLINE ONLINE rac2

ora.rac2.gsd application ONLINE ONLINE rac2

ora.rac2.ons application ONLINE ONLINE rac2

ora.rac2.vip application ONLINE ONLINE rac2

利於-p選項，得到資源配置屬性。

[root@rac2 bin]# crs_stat -p ora.rac2.vip

NAME=ora.rac2.vip

TYPE=application

ACTION_SCRIPT=/opt/oracle/product/10.2.0/crs_1/bin/racgwrap

ACTIVE_PLACEMENT=1

AUTO_START=1

CHECK_INTERVAL=60

DESCRIPTION=CRS application for VIP on a node

…………………………………………

USR_ORA_STOP_MODE=immediate

USR_ORA_STOP_TIMEOUT=0

USR_ORA_VIP=192.168.18.112

利用-p參數，得到資源權限。

[root@rac2 bin]# crs_stat -ls|grep vip

ora.rac1.vip root oinstall rwxr-xr—

ora.rac2.vip root oinstall rwxr-xr--

主要參數有-t/-v/-p/-ls/-f等。具體能夠參見crs_stat –h

集羣資源啓動/中止CRS_START/CRS_STOP

這組命令主要負責各個節點上resources的啓動/中止。能夠針對全局資源(例如：crs_stop –all，表示中止全部節點上的resources),也能夠針對節點上的某個特定的資源（例如：crs_start ora.rac2.ons,表示啓動節點rac2上的ONS）。

集羣資源配置CRS_REGISTER/CRS_UNREGISTER/CRS_PROFILE/CRS_SETPERM

這組命令主要負責集羣資源的添加刪除以及配置。

CRS_PROFILE:用來生成resource的profile文件(固然咱們也能夠手動編輯或者經過現有生成)，默認存放路徑$ORA_CRS_HOME/crs/profile目錄下，加參數-dir 手動指定目錄。默認名稱爲resource_name.cap.

crs_profile -create resource_name -t application –a .. –r .. –o..

表3.1爲 crs_profile中參數配置說明（比較多，挑一些說吧）：

參數名稱	說明	參數指令（以create爲例）
NAME	資源名稱	crs_profile –create resource_name
TYPE	資源類型(application, generic)	crs_profile – create resource_name –t …
ACTION_SCRIPT	用來管理HA方案腳本	crs_profile – create resource_name –a …
ACTIVE_PLACEMENT	資源貯存的位置/節點	crs_profile –create resource_name –o –ap …
AUTO_START	資源自啓動	crs_profile –create resource_name –o –as …
CHECK_INTERVAL	資源監控間隔	crs_profile –create resource_name –o –ci …
FAILOVER_DELAY	資源failover的等待時間	crs_profile –create resource_name –o –fd …
FAILURE_INTERVAL	資源重啓嘗試間隔	crs_profile –create resource_name –o –fi …
FAILURE_THRESHOLD	資源重啓嘗試次數(最大20次)	crs_profile –create resource_name –o –ft …
HOSTING_MEMBERS	資源啓動或者failover的首要節點選擇	crs_profile –create resource_name –h …
PLACEMENT	資源啓動或者failover的節點選擇模式（balanced，balanced，balanced）	crs_profile – create resource_name -p
REQUIRED_RESOURCES	當前資源所依賴的資源	crs_profile – create resource_name -r
RESTART_ATTEMPTS	資源重配置以前的嘗試啓動次數	crs_profile –create resource_name –o –ra …
SCRIPT_TIMEOUT	等待ACTION_SCRIPT的結果返回時間	crs_profile –create resource_name –o –st …
USR_ORA_VIP	Vip地址	crs_profile –create vip_name -t application –a $ORA_CRS_HOME/bin/uservip –o oi=…,ov=…,on=…

crs_profile －update resource_name … 用來更新現有profile(更新的只是profile，而並非對已經註冊到crs裏面的資源屬性的更改)

crs_register負責將resource的註冊到OCR。註冊的方法是先生成profile，而後運行

crs_register resource [-dir …]命令，同時，crs_register也具備update resource功能，具體辦法能夠更新resource對應的profile文件，而後運行crs_register -u resource_name [-dir …] 或者直接發佈crs_register –update resource_name …

好比，我將rac節點上的vip改成手動啓動。

[root@rac1 crs]# crs_register -update ora.rac1.vip -o as=0

[root@rac1 crs]# crs_stat -p ora.rac1.vip|grep AUTO_START

AUTO_START=0

crs_unregister負責將resource從ocr中移除。必要時候須要加－f參數。

crs_setperm用來設置resource的權限（諸如設置owner，用戶的讀寫權限等），更改owner用-o參數，更改group用-g，更改用戶權限用-u，在此很少舉例了。

<2>.CRSCTL

用crsctl check crs，檢查crs的健康狀況。

[root@rac1 ~]# crsctl check crs

CSS appears healthy

CRS appears healthy

EVM appears healthy

用crsctl控制CRS服務

crsctl start|stop|enable|disable crs

用crsctl啓動/中止resource

[root@rac1 ~]# crsctl stop resources

Stopping resources.

Successfully stopped CRS resources

[root@rac1 ~]# crsctl start resources

Starting resources.

Successfully started CRS resources

用crsctl檢查以及添加、刪除voting disk

下面講述。

更多參見crsctl help。

<3>SRVCTL

SRVCTL是一個強大的CRS和RDBMS的管理配置工具。相關用法參照srvctl -h

（1） srvctl add/delete .. 添加刪除資源。譬如咱們在進行數據庫單實例遷移到rac的時候，能夠用這個工具手工註冊database或者asm實例到OCR。

（2） srvctl status … 資源的狀態監測

（3） srvctl start/stop … 資源的啓動/中止，這個能夠和crs_start/crs_stop互交使用。

（4） srvctl modify .. 從新定義資源的屬性

………………………………………………………..

(2).OCR的管理維護
<1> OCR的狀態驗證：

能夠使用ocrcheck工具來驗證OCR的狀態以及空間使用狀況。在Lunix下，/etc/oracle/ocr.loc文件記錄了OCR使用的設備狀況。

[root@rac1]# ocrcheck

Status of Oracle Cluster Registry is as follows :

Version : 2

Total space (kbytes) : 497896

Used space (kbytes) : 3996

Available space (kbytes) : 493900

ID : 958197763

Device/File Name : /dev/raw/raw5

Device/File integrity check succeeded

Device/File not configured

Cluster registry integrity check succeeded

<2> 在線添加/刪除ocrmirror

OCR支持一個鏡像，添加/刪除鏡像能夠在線完成，主要在某個online的節點上執行命令便可。

[root@rac1]#ocrconfig -replace ocrmirror /dev/raw/raw5

[root@rac1 oracle]# cat /etc/oracle/ocr.loc

#Device/file getting replaced by device /dev/raw/raw5

ocrconfig_loc=/dev/raw/raw1

ocrmirrorconfig_loc=/dev/raw/raw5

可見，ocr.loc被自動更新。

移除ocr或者鏡像的時候，只要不帶路徑，便可。

當一個crs中存在ocr和鏡像的時候，若是移除ocr，鏡像會自動轉變成ocr的角色。

[root@rac1]# ocrconfig -replace ocr

[root@rac1]# cat /etc/oracle/ocr.loc

#Device/file /dev/raw/raw1 being deleted

ocrconfig_loc=/dev/raw/raw5

能夠看到如今的ocrconfig_loc自動變爲先前的ocrmirrorconfig_loc設備。

<3> 邏輯備份/恢復

備份命令：

ocrconfig –export [ path ]

還原命令

ocrconfig –import [ path ]

還原OCR的時候，須要停掉各節點crs服務。還原完成後，從新啓動CRS。(若是有必要，注意在每一個節點分別修改ocr.loc的對應使用設備)

<4> 物理備份/恢復

CRSD負責每4個小時進行一次OCR的備份，默認備份路徑在$ORA_CRS_HOME/cdate/crs下，

能夠使用ocrConfig –showbackup查看備份狀況，若是想更改物理備份路徑，能夠使用ocrconfig –backuploc [ path ] 來完成

物理恢復命令：

ocrconfig –restore [ path ]

一樣,還原OCR的時候，須要停掉各節點crs服務。還原完成後，從新啓動CRS。(若是有必要，注意在每一個節點分別修改ocr.loc的對應使用設備)

<5> ocrdump

ocrdump能夠將ocr信息導出成ascii文本，用於給Oracle Supoort提供檢修。

命令以下：

ocrdump

(3).Voting disk管理維護
Voting disk的維護相對簡單些。

<1> Votingdisk 狀態查詢

[root@rac1]# crsctl query css votedisk

0 /dev/raw/raw2

located 1 votedisk(s).

<2>在線添加、刪除votingdisk

Oracle建議配置奇數個votingdisk，添加/刪除能夠在線完成，在某個online的節點上執行命令便可。

添加votingdisk命令：

crsctl add css votedisk [path] -force

刪除votingdisk命令：

crsctl add css votedisk [path] -force

<3>votingdisk備份恢復

備份、恢復採用dd命令。恢復的時候，注意停掉各節點上的CRS服務。

2.RDBMS管理維護

(1).spfile以及相關參數說明

最廣泛狀況，節點共用同一個spfile文件，放置在共享存儲上，而每一個節點上，相應目錄下有一個pfile文件，而這個pfile文件指向共享存儲上的spfile。

當咱們須要修改某一節點上的paremeter的時候，須要顯示的指定sid，例如：

SQL>alter system set sga_target=1024M scope=spfile sid=’rac1’;

System Altered.

這樣，節點rac1上的sga_target參數被修改，不會影響其他節點上的參數設置。若是不加sid，默認爲sid＝’*’，也就是對全部節點生效。

RAC下，有一些不一樣與單實例的參數，列舉以下：

① cluster_database
通常狀況下，該參數在rac各實例下應該設置爲true。在一些特別狀況下，好比upgrade等，須要將該參數設置成false。
② db_name/db_unique_name/instance_name
各節點db_name須要一致，db_unique_name也須要一致(這與standby是不一樣的)。而instance_name配置成各個節點的實例名稱。
③ instance_number
該參數表示節點上實例的實例號。
④ thread
該參數用來標示實例使用的redo線程。線程號與節點號/實例號沒有直接關聯。
⑤ local_listener
該參數用來手工註冊監聽。爲解決ORA-12514錯誤，能夠設置該參數。
⑥ remote_listener
該參數用來進行服務器端負載均衡配置。
⑦ cluster_interconnects
該參數用來指定集羣中IPC通訊的網絡。若是集羣中有多種網絡用於高速互聯，須要配置該參數。對於多個IP地址，用冒號將其隔開。對於集羣中當前使用的互聯地址，能夠查詢視圖gv$cluster_interconnects或着oradebug ipc來查看。
⑧ max_commit_propagation_delay
該參數用於配置SCN的產生機制。在rac下,SCN的同步有2種模式:(1) Lamport Scheme.該模式下，由GES管理SCN的傳播同步，max_commit_propagation_delay表示SCN同步所容許的最大時間。在該模式下，全局SCN並不是徹底同步，這在高併發的OLTP系統中，可能會對應用形成必定的影響。(2) Broadcast on Commit scheme. 該模式下，一旦任何一個實例上事務發佈commit，都當即同步SCN到全局。
在10g R1下，該參數默認數值爲700，即採用Lamport Scheme模式。而在10g R2下，該參數默認數值爲0，採用Broadcast on Commit scheme模式 (設置小於700的某一值，都將採用該模式) 。採用何種方式，能夠從alert.log中獲知。該參數值須要每一個節點保持一致。

(2). Redo/Undo管理
?RAC下的Redo管理
同單實例的系統同樣，每一個節點實例都須要至少2組logfile。各節點實例有本身獨立的重作日誌線程(由初始化參數thread定義)，例如：

SQL> select b.THREAD#,a.GROUP#,a.STATUS,a.MEMBER,b.BYTES,b.ARCHIVED,b.STATUS from v$logfile a,v$log b where a.GROUP#=b.GROUP#;
THREAD# GROUP# STATUS  MEMBER                               BYTES  ARCHIVED  STATUS
------------------- ------- --------------------------------------------------
1  1   STALE +DATA/demo/onlinelog/group_1.257.660614753  52428800 YES  INACTIVE
1  2          +DATA/demo/onlinelog/group_2.258.660614755  52428800  NO   CURRENT
2  3          +DATA/demo/onlinelog/group_3.265.660615545  52428800  NO   CURRENT
2  4  STALE  +DATA/demo/onlinelog/group_4.266.660615543  52428800 YES  INACTIVE

重作日誌須要部署到共享存儲中，必須保證可被全部的集羣內的節點實例訪問。當某個節點實例進行實例/介質恢復的時候，該節點上的實例將能夠應用集羣下全部節點實例上的重作日誌文件(若是須要)，從而保證恢復能夠在任意可用節點進行。

?RAC下alter system switch logfile 與alter system archive log current 區別
alter system switch logfile僅對當前發佈節點上的對應redo thread進行日誌切換並歸檔。
alter system archive log current對集羣內全部節點實例上的redo thread進行切換並歸檔（在節點實例可用狀況下，分別歸檔到各節點主機的歸檔目的地，當節點不可用時候，該線程日誌歸檔到命令發佈節點的歸檔目的地）

?RAC下的Undo管理
RAC下的每一個節點實例，也須要有本身單獨的撤銷表空間。由初始化參數 *.Undo_tablespace 指定。同REDO同樣，UNDO表空間也須要部署到共享存儲，雖然每一個節點上UNDO的使用是獨立的，但須要保證集羣內其餘節點實例對其訪問，以完成構造讀一致性等要求。

SQL>alter system set undo_tablespace=undo1 sid=’demo1’;
SQL>alter system set undo_tablespace=undo2 sid=’demo2’;

(3).Archivelog/flashback配置管理

在RAC下，Archivelog能夠放置到本地磁盤，也能夠放置到共享存儲。須要對Archivelog的放置有合理的部署，若是放置到本地磁盤，會增長備份恢復的複雜程度。
閃回區必須部署到共享存儲上，開啓前，須要配置db_recovery_file_dest、db_recovery_file_dest_size、db_flashback_retention_target等參數。
下面在一個非歸檔非閃回的database上，開始歸檔與閃回。
?更改相關參數

SQL>alter system set log_archive_dest_1='location=/archive/demo1' sid='demo1';

System altered

SQL> alter system set log_archive_dest_1='location=/archive/demo2' sid='demo2';

System altered

SQL> alter system set db_recovery_file_dest_size=512M;

System altered

SQL> alter system set db_recovery_file_dest='+DG1';

System altered

?停掉全部節點實例.開啓過程在一個實例上完成。

rac1-> srvctl stop instance -d demo -i demo1

rac1-> srvctl stop instance -d demo -i demo2  

rac1-> sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on Sun Aug 3 22:06:50 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

SQL> conn /as sysdba

Connected to an idle instance.

SQL> startup mount;

ORACLE instance started.

Total System Global Area  167772160 bytes

Fixed Size                  1218316  bytes

Variable Size             100665588 bytes

Database Buffers           62914560 bytes

Redo Buffers                2973696 bytes

Database mounted.

SQL> alter database archivelog;

Database altered.

SQL> alter database flashback on;

Database altered.

SQL> alter database open;

Database altered.

SQL> select NAME,LOG_MODE,FLASHBACK_ON from v$database;

NAME      LOG_MODE     FLASHBACK_ON

--------- ------------ ------------------

DEMO      ARCHIVELOG   YES

10G下，開啓歸檔和閃回並不須要像9i那樣，設置初始化參數cluster_database＝false.這無疑簡化了操做。

(4).ASM下的RAC管理
?ASM下的參數文件

RAC下，每一個節點上有運行有一個ASM實例，而rdbms instance就運行在這個asm實例上。Asm實例是本地的。同rdbms實例同樣，他須要有參數文件，參數文件在每一個節點的相應目錄下。
下面是個人ASM實例下的pfile文件：

cluster_database=true

background_dump_dest=/opt/oracle/admin/+ASM/bdump

core_dump_dest=/opt/oracle/admin/+ASM/cdump

user_dump_dest=/opt/oracle/admin/+ASM/udump

instance_type=asm

large_pool_size=12M

remote_login_passwordfile=exclusive

asm_diskgroups='DG1'

+ASM2.instance_number=2

+ASM1.instance_number=1

簡單介紹幾個asm實例中比較重要的參數:
instance_type：用來講明實例是ASM 仍是RDBMS 類型
asm_diskgroups：ASM磁盤組，asm實例啓動的時候會自動mount
asm_diskstring：該參數用來講明可以建立diskgroup的磁盤設備,默認值是NULL
asm_power_limit:該參數用來設置進程 ARBx 的數量，負責控制負載平衡操做的速度。取值 從 0 到 11。默認值爲1。

?用於記錄ASM實例信息的數據字典。
V$ASM_DISK/ V$ASM_DISK_STAT：記錄能夠被ASM實例識別的磁盤信息，但這些磁盤並不必定是正在被實例使用的。
V$ASM_DISKGROUP/ V$ASM_DISKGROUP_STAT：記錄asm下的diskgroup信息。
V$ASM_ALIAS：記錄diskgroup文件的別名信息。
V$ASM_FILE：記錄diskgroup中的文件信息。
V$ASM_OPERATION：記錄ASM實例中當前運行的一個長時間操做信息。
V$ASM_TEMPLATE：記錄diskgroup模板。
V$ASM_CLIENT：記錄使用該asm實例下的diskgroup的rdbms實例信息。

?RAC下ASM磁盤組/文件管理操做
<1>.RAC下在線添加、刪除磁盤組
在一個節點上添加diskgroup，集羣上另外的節點並不會自動mount新添加的diskgroup，須要手動執行。
節點1：

SQL> show parameter asm_diskgroups

NAME                                 TYPE        VALUE

------------------------------------ -----------

asm_diskgroups                       string      DATA, DG1

SQL>CREATE DISKGROUP DATA2  NORMAL REDUNDANCY

FAILGROUP DATA2_gp1 DISK '/dev/raw/raw6' FAILGROUP DATA2_gp2 DISK '/dev/raw/raw7';

Diskgroup created.

SQL> show parameter asm_diskgroups

NAME                                 TYPE        VALUE

------------------------------------ -----------

asm_diskgroups                       string      DATA, DG1, DATA2

此時觀察節點2，新加的磁盤組沒有被mount。

SQL> show parameter asm_diskgroups

NAME                                 TYPE        VALUE

-----------------------------------------------

asm_diskgroups                          string        DATA, DG1

SQL>select group_number,type,state,type,total_mb,free_mb from v$asm_diskgroup_stat;

GROUP_NUMBER   STATE       TYPE     TOTAL_MB    FREE_MB

--------------- --------------- ------------------------

           1     CONNECTED   EXTERN       5726       4217

           2     CONNECTED   EXTERN        415        297

           0    DISMOUNTED                     0         0

SQL>alter diskgroup DATA2 mount;

刪除diskgroup時，保留一個節點diskgroup爲mount狀態，將其他節點上的diskgroup dismount，而後執行刪除命令。

<2>.在線添加、刪除磁盤
RAC下在線添加磁盤與刪除磁盤與單實例並不差異。須要注意該操做會引發磁盤組的從新平衡，並確保刪除磁盤的時候該磁盤組有足夠的剩餘空間。
節點1：

SQL> alter diskgroup dg6 add disk '/dev/raw/raw7' name dg6_disk7;

Diskgroup altered.

節點2上查詢：

SQL>select GROUP_NUMBER,path,NAME,MOUNT_STATUS,HEADER_STATUS,MODE_STATUS,STATE from v$asm_disk_stat where NAME is not null;

GROUP_NUMBER PATH     NAME       MOUNT_S HEADER_STATU MODE_ST STATE

------------ ---------------- ---------- ------- ------------ -------

           1 /dev/raw/raw3    DATA_0000  CACHED  MEMBER       ONLINE  NORMAL

           2 /dev/raw/raw4    DG1_0000   CACHED  MEMBER       ONLINE  NORMAL

           3 /dev/raw/raw6    DG6_0001   CACHED  MEMBER       ONLINE  NORMAL

           3 /dev/raw/raw7    DG6_DISK7  CACHED  MEMBER       ONLINE  NORMAL

刪除磁盤在某一節點操做便可，不作舉例驗證。
關於ASM的更多管理命令，就很少列舉了。
3.Database備份/恢復

RAC下的備份恢復跟單實例的備份恢復實質上沒有太大的差異，須要注意的是備份/恢復的時候當前節點對全部數據文件/歸檔日誌的可見。在一個數據文件和歸檔日誌所有放在共享存儲上的RAC系統，備份與恢復過程與單實例下的幾乎同樣。而歸檔日誌若是採用的是本地磁盤，就須要另加註意。下面分別來模擬這個備份恢復過程。
(1).Archivelog對各節點可見的備份/恢復
在這種模式下，備份恢復能夠在任意一個可用節點執行便可，跟單實例並不太大區別。
?對database進行備份

RMAN>run{allocate channel orademo type disk;

backup database format '/backup/database/db_%s_%p_%t' plus archivelog format  '/backup/database/arch_%s_%p_%t' delete input;

backup current controlfile format '/backup/database/contr_%s_%p_%t';}

allocated channel: orademo

channel orademo: sid=130 instance=demo2 devtype=DISK

Starting backup at 03-MAY-08

current log archived

channel orademo: starting archive log backupset

channel orademo: specifying archive log(s) in backup set

input archive log thread=1 sequence=5 recid=70 stamp=661823848

input archive log thread=1 sequence=6 recid=72 stamp=661823865

……………………………………..

Finished backup at 03-MAY-08

released channel: orademo

?添加數據，用於測試恢復效果

SQL> create table kevinyuan.test_b as select * from dba_data_files;

Table created

SQL> alter system switch logfile;

System altered

SQL> insert into kevinyuan.test_b select * from dba_data_files;

6 rows inserted

SQL> commit;

Commit complete

SQL> select count(*) from kevinyuan.test_b;

  COUNT(*)

        12

?模擬故障/恢復

RMAN> run {restore controlfile from '/backup/database/contr_16_1_661823935';

sql 'alter database mount';

restore database;

recover database;

sql 'alter database open resetlogs'; }

Starting restore at 04-MAY-08

allocated channel: ORA_DISK_1

…………………………………………………………………………..

archive log filename=+DATA/demo/onlinelog/group_4.266.660615543 thread=2 sequence=11

archive log filename=+DATA/demo/onlinelog/group_3.265.660615545 thread=2 sequence=12

media recovery complete, elapsed time: 00:00:00

Finished recover at 04-MAY-08

sql statement: alter database open resetlogs

?恢復完畢，來看一下驗證數據：

SQL> select count(*) from kevinyuan.test_b;

  COUNT(*)

        12

(2). Archivelog對各節點不可見的備份/恢復

若是arhivelog採用本地磁盤,歸檔日誌並非對任意節點可見。備份archivelog的時候，若是採用和上述相似的備份方案，必然會致使一些歸檔日誌因爲沒法access而拋出異常。能夠採起以下的備份方式，目的就是使得備份通道可以access全部的數據字典中記錄的歸檔日誌信息。
恢復的時候,copy全部節點產生的相關備份片/集和歸檔日誌文件到待恢復節點，在一個節點上執行restore/recover操做便可。
模擬一下這個操做。

SQL> alter system set log_archive_dest_1='location=/archive/demo1/' sid='demo1';

System altered

SQL> alter system set log_archive_dest_1='location=/archive/demo2/' sid='demo2';

System altered

(1)備份數據庫

RMAN>run{allocate channel orademo1 type disk connect sys/kevinyuan@demo1;

allocate channel orademo2 type disk connect

sys/kevinyuan@demo2;

backup database format '/backup/database/db_%s_%p_%t'

plus archivelog format '/backup/database/arch_%s_%p_%t' delete

input;

backup current controlfile format

'/backup/database/contr_%s_%p_%t;}

allocated channel:

orademo1

channel orademo1: sid=133 instance=demo1 devtype=DISK

allocated

channel: orademo2

channel orademo2: sid=151 instance=demo2

devtype=DISK

Starting backup at 04-MAY-08

current log archived

channel

orademo2: starting archive log backupset

channel orademo2: specifying archive

log(s) in backup set

input archive log thread=2 sequence=4 recid=89

stamp=661826286

………………………………………………………………….

channel orademo1: finished

piece 1 at 04-MAY-08

piece handle=/backup/database/contr_28_1_661826504

tag=TAG20080504T004130 comment=NONE

channel orademo1: backup set complete,

elapsed time: 00:00:09

Finished backup at 04-MAY-08

released channel:

orademo1

released channel:

orademo2

(2)COPY節點2上的備份文件/歸檔日誌文件到節點1相應目錄下。

rac2-> scp /backup/database/*  rac1:/backup/database/

rac2-> scp /archive/demo2/* rac1:/archive/demo1

(3)恢復database

RMAN>run{restore controlfile from '/backup/database/contr_28_1_661826504';

sql 'alter database mount';

restore database;

recover database;

sql 'alter database open resetlogs';}

starting restore at 04-MAY-08

using target database

control file instead of recovery catalog

allocated channel:

ORA_DISK_1

channel ORA_DISK_1: sid=147 instance=demo1 devtype=DISK

channel

ORA_DISK_1: restoring control file

channel ORA_DISK_1: restore complete,

elapsed time: 00:00:20

…………………………………………………………………………………

archive log

filename=+DATA/demo/onlinelog/group_3.265.660615545 thread=2

sequence=7

archive log

filename=+DATA/demo/onlinelog/group_4.266.660615543

thread=2 sequence=8

media recovery complete, elapsed time:

00:00:06

Finished recover at 04-MAY-08

sql statement: alter database open

resetlogs

至此，恢復完成。

生產庫的備份須要縝密部署與模擬測試，不一樣的數據庫類型也須要制定不一樣的方案實現。對DATABASE來講，備份重於泰山，不能抱有任何僥倖心理。

Service.Failover and Load Balance

1.Service
服務是rac體系中至關重要的概念，它爲應用提供高可用和多樣化的解決方案。實際中，咱們能夠建立不一樣性質的service來知足咱們應用的不一樣需求。

10gR2下，能夠經過如下幾個方式建立服務。
(1).使用dbca
(2).使用srvctl

node1->srvctl add service -d demo -s srv_1 -r node1 -a node2

node1-> srvctl start service -d demo -s srv_1

node1-> crs_stat –t

Name Type Target State Host

ora.demo.db application ONLINE ONLINE node1

ora….o1.inst application ONLINE ONLINE node1

ora….o2.inst application ONLINE OFFLINE

ora….rv_1.cs application ONLINE ONLINE node1

ora….mo1.srv application ONLINE ONLINE node1

SQL> show parameter service

NAME TYPE VALUE

———————————— ———– ———–

service_names string demo,srv_1

(3).使用dbms_service命令建立
10g提供了dbms_service用於管理服務並進行功能擴展.

SQL>EXEC DBMS_SERVICE.CREATE_SERVICE(SERVICE_NAME=>’srv_2′,NETWORK_NAME=>’ srv_2′);

PL/SQL procedure successfully completed

SQL> exec DBMS_SERVICE.START_SERVICE(service_name => ’srv_2′,instance_name => ‘demo1′);

PL/SQL procedure successfully completed

SQL> show parameter service

NAME TYPE VALUE
———————————— ———– ———–

service_names string demo,srv_2

(4).其餘等..
無論採用哪一種方式，實質都是經過修改service_names而向lisnter動態註冊服務.
2. failover and load banance

RAC爲應用提供了高性能和高可用的服務，對用戶來說，核心的功能即是failover與load banance.
(1)Failover
在10gR2版本里，Failover的實現方式有兩種，一種是TAF(Transparent Application Failover), 一種是FCF(Fast Connection Failover).
TAF以及實現:
TAF是net層透明故障轉移,是一種被動的故障轉移方式, 依賴於VIP.能夠經過客戶端和服務器端配置taf的策略.
<1> client端taf配置
如下是一個簡單的具備taf功能的tnsnames.ora 內容

demo =

(DESCRIPTION =

(FAILOVER=ON)

(ADDRESS=(PROTOCOL=TCP)(HOST=10.194.129.145)(PORT=1521))

(ADDRESS=(PROTOCOL=TCP)(HOST=10.194.129.146)(PORT=1521))

(CONNECT_DATA =

(SERVICE_NAME = demo)

(SERVER=DEDICATED)

(FAILOVER_MODE=(TYPE=SELECT)

(METHOD=BASIC)

(RETRIES=50)

(DELAY=5)

)

)

)

控制TAF策略的參數說明：

參數	描述
FAILOVER	Failover控制開關（on/off），若是爲off，不提供故障切換功能，但鏈接時會對address列表進行依次嘗試，直到找到可用爲止
TYPE	兩種類型：session /select Session: 提供session級別的故障切換。 Select：提供select級別的故障切換，切換過程對查詢語句透明，但事物類處理須要回滾操做
METHOD	兩種類型:basic/preconnect Basic:client同時只鏈接一個節點，故障切換時跳轉到另外節點 Preconnect：須要與backup同時使用，client同時鏈接到主節點和backup節點
BACKUP	採用Preconnect模式的備用鏈接配置
RETRIES	故障切換時重試次數
DELAY	故障切換時重試間隔時間

<2> Server端TAF配置
10gR2提供Server端的TAF配置，須要調用dbms_service包來在實例上進行修改。

SQL> exec dbms_service.modify_service(service_name => ‘DEMO’,failover_method => ‘BASIC’,failover_type => ‘SELECT’,failover_retries => 180,failover_delay => 5);

客戶端鏈接字符串修改爲以下便可：

demo =

(DESCRIPTION =

(ADDRESS=(PROTOCOL=TCP)(HOST=10.194.129.145)(PORT=1521))

(ADDRESS=(PROTOCOL=TCP)(HOST=10.194.129.146)(PORT=1521))

(CONNECT_DATA =

(SERVICE_NAME = demo)

(SERVER=DEDICATED)

)

)

FCF及實現
FCF是10g引進的一種新的failover機制，它依靠各節點的ons進程，經過廣播FAN事件來得到各節點的運行狀況，是一種前攝性的判斷，支持JDBC/OCI/ODP.NET
(1).ons配置
onsctl工具配置各節點的local /remote節點以及端口.配置文件路徑:$ORACLE_HOME/opmn/ons.config.
使用 onsctl debug 跟蹤ons進程是否正常運行。
(2).配置鏈接池（以jdbc爲例）
須要鏈接池支持Implicit Connection Cache，設置FastConnectionFailoverEnabled=true.
將ojdbc14.jar / ons.jar等加入CLASSPATH.具體代碼能夠參見聯機文檔或metalink相關文檔.
(2) Load Balance
10g的 load balance同前版本相比有了很大功能上的改進，依據Load Balancing Advisory，提供了Runtime Connection Load Balancing的策略，但我的認爲這也是個相對矛盾所在。越是細化的負載均衡機制，越是有加劇cache fusion的可能，這對rac的總體性能是個考驗。
load balance主要有兩種實現方式:一種是Connection Load Balancing(CLB)，另一種是Runtime Connection Load Balancing(RCLB)。
CLB分爲客戶端client-side和服務器端server-side兩種。
client-side須要在tnsname.ora添加LOAD_BALANCE=ON來實現，提供基於平衡鏈接數的負載方案.
server-side須要修改remote_listener參數,讓listener能監聽到集羣中的全部節點,經過PMON來收集節點上的負載信息。
FCF默認支持RCLB功能，RCLB經過load balancing advisory事件來對鏈接提供更好的服務。RCLB有兩種負載平衡方案可供選擇—-基於整體service name和基於整體Throughput。能夠經過dbms_service來設置具體的goal方案。

SQL> exec dbms_service.modify_service(service_name => ‘TEST’, goal => DBMS_SERVICE.GOAL_SERVICE_TIME);

至於這兩種方式的具體差別，在個人測試中，並無獲得明顯的體現。
Load Balanc這部分是我存疑最多的地方，查閱了不少文檔，說法不一，且沒有翔實的案例證實，在此也但願有過研究的朋友們作指正。

RAC下其餘維護實施相關/案例

本環節側重一些RAC工程維護相關的實際案例,暫舉例如下案例

1.集羣中主機名的更改
2.集羣中IP地址的更改
3.集羣中節點的添加/刪除
4.升級:9i rac升級10g rac
5.rac + dg 搭建
6.其餘

<一> 集羣中主機名的更改
如下爲一個實際案例，下表爲更改先後的主機名稱對比

hostname:node1/node2 —-> td1/td2

private_name:node1_priv/node2_priv —-> td1_priv/td2_priv

vip_name:node1_vip/node2_vip —-> td1_vip/td2_vip

1.生成listener的cap文件

node1->crs_stat –p ora.node1.LISTENER_NODE1.lsnr>/home/oracle/ora.node1.LISTENER_NODE1.lsnr.cap

node1->crs_stat –p ora.node2.LISTENER_NODE2.lsnr>/home/oracle/ora.node2.LISTENER_NODE2.lsnr.cap

2.停掉全部的資源，備份ocr、votingdisk並從新格式化
備份OCR

[root@node1 backup]# ocrcheck

Status of Oracle Cluster Registry is as follows :

Version : 2

Total space (kbytes) : 104176

Used space (kbytes) : 4424

Available space (kbytes) : 99752

ID : 2042344313

Device/File Name : /dev/raw/raw1

Device/File integrity check succeeded

Device/File not configured

Cluster registry integrity check succeeded

[root@node1 init.d]# ocrconfig -export /backup/ocr_1.bak

備份votedisk

[root@node1 ~]# crsctl query css votedisk

0. 0 /dev/raw/raw110

located 1 votedisk(s).

[root@node1 ~]# dd if=/dev/raw/raw110 of=/backup/votedisk.bak

從新格式化

[root@td01 ~]# dd if=/dev/zero of=/dev/raw/raw1 bs=1024k count=1

[root@td01 ~]# dd if=/dev/zero of=/dev/raw/raw110 bs=1024k count=1

3.OS上修改hostname並編輯相關文件，重啓主機（步驟略）

4.從新配置集羣互信。（步驟略）

5.編輯$ORA_CRS_HOME/ install/rootconfig文件，修改如下爲你實際的狀況。

ORA_CRS_HOME=/opt/oracle/product/10.2.0/crs_1
CRS_ORACLE_OWNER=oracle
CRS_DBA_GROUP=oinstall
CRS_VNDR_CLUSTER=false
CRS_OCR_LOCATIONS=/dev/raw/raw1
CRS_CLUSTER_NAME=crs
CRS_HOST_NAME_LIST=td1,1,td2,2
CRS_NODE_NAME_LIST=td1,1,td2,2
CRS_PRIVATE_NAME_LIST=td1-priv,1,td2-priv,2
CRS_LANGUAGE_ID=’AMERICAN_AMERICA.WE8ISO8859P1′
CRS_VOTING_DISKS=/dev/raw/raw110
CRS_NODELIST=td1,td2
CRS_NODEVIPS=’td1/td1-vip/255.255.255.0/eth0,td2/td2-vip/255.255.255.0/eth0′

在每一個節點依次執行：

[root@td2 install]# /opt/oracle/product/10.2.0/crs_1/install/rootconfig

Checking to see if Oracle CRS stack is already configured

Setting the permissions on OCR backup directory

Setting up NS directories

Oracle Cluster Registry configuration upgraded successfully

WARNING: directory ‘/opt/oracle/product/10.2.0′ is not owned by root

WARNING: directory ‘/opt/oracle/product’ is not owned by root

WARNING: directory ‘/opt/oracle’ is not owned by root

WARNING: directory ‘/opt’ is not owned by root

clscfg: EXISTING configuration version 3 detected.

clscfg: version 3 is 10G Release 2.

Successfully accumulated necessary OCR keys.

Using ports: CSS=49895 CRS=49896 EVMC=49898 and EVMR=49897.

node :

node 1: td1 td1-priv td1

node 2: td2 td2-priv td2

clscfg: Arguments check out successfully.

NO KEYS WERE WRITTEN. Supply -force parameter to override.

-force is destructive and will destroy any previous cluster

configuration.

Oracle Cluster Registry for cluster has already been initialized

Startup will be queued to init within 30 seconds.

Adding daemons to inittab

Expecting the CRS daemons to be up within 600 seconds.

CSS is active on these nodes.

td1

td2

CSS is active on all nodes.

Waiting for the Oracle CRSD and EVMD to start

Oracle CRS stack installed and running under init(1M)

Running vipca(silent) for configuring nodeapps

Creating VIP application resource on (2) nodes…

Creating GSD application resource on (2) nodes…

Creating ONS application resource on (2) nodes…

Starting VIP application resource on (2) nodes…

Starting GSD application resource on (2) nodes…

Starting ONS application resource on (2) nodes…

若是是10.2.0.1 版本，在最後一個節點上執行的時候會由於vip的bug拋出異常，在該節點上調用VIPCA圖形化界面。

這樣gsd、ons和vip已經所有註冊到OCR中。

[root@td1 install]# crs_stat –t

Name Type Target State Host

ora.td1.gsd application ONLINE ONLINE td1

ora.td1.ons application ONLINE ONLINE td1

ora.td1.vip application ONLINE ONLINE td1

ora.td2.gsd application ONLINE ONLINE td2

ora.td2.ons application ONLINE ONLINE td2

ora.td2.vip application ONLINE ONLINE td2

6.使用oifcfg配置共有/私連網絡

td1-> oifcfg setif -global eth0/10.194.129.0:public

td1-> oifcfg setif -global eth1/10.10.10.0:cluster_interconnect

7.註冊其餘資源到集羣

(1)註冊監聽到集羣
修改監聽配置文件lisntener.ora並編輯生成的cap文件（更名），更改其中用到的hostname.

td1-> crs_register ora.td1.LISTENER_TD1.lsnr -dir /home/oracle

td1-> crs_register ora.td2.LISTENER_TD2.lsnr -dir /home/oracle

或者使用netca圖形化界面來配置監聽.

(2)註冊ASM實例到集羣(若是使用ASM)

td1->srvctl add asm -n td1 -i ASM1 -o $ORACLE_HOME

td1->srvctl add asm -n td2 -i ASM2 -o $ORACLE_HOME

(3)註冊instance/database到集羣

td1->srvctl add database -d demo -o $ORACLE_HOME

td1->srvctl add instance -d demo -i demo1 -n td1

td1->srvctl add instance -d demo -i demo2 -n td2

驗證：

td1-> crs_stat -t
Name Type Target State Host
————————————————————
ora.demo.db application ONLINE ONLINE td1
ora….o1.inst application ONLINE ONLINE td1
ora….o2.inst application ONLINE ONLINE td2
ora….SM1.asm application ONLINE ONLINE td1
ora….D1.lsnr application ONLINE ONLINE td1
ora.td1.gsd application ONLINE ONLINE td1
ora.td1.ons application ONLINE ONLINE td1
ora.td1.vip application ONLINE ONLINE td1
ora….SM2.asm application ONLINE ONLINE td2
ora….D2.lsnr application ONLINE ONLINE td2
ora.td2.gsd application ONLINE ONLINE td2
ora.td2.ons application ONLINE ONLINE td2
ora.td2.vip application ONLINE ONLINE td2

登錄數據庫檢查db使用的內鏈接鏈路

SQL> select * from v$cluster_interconnects;
NAME IP_ADDRESS IS_PUBLIC SOURCE
————— —————- ——— ——————————-
eth1 10.10.10.145 NO Oracle Cluster Repository

若是使用了OCFS做爲共享文件格式，注意在啓動數據庫前檢查相應OCFS的配置並確認ocfs是否能正常掛載使用。

2.集羣中IP地址的更改
IP地址的更改比hostname的更改相對容易一些。對於同網段的public/private IP更改，無需進行特別操做。若是是不一樣網段，須要使用oifcfg處理。由於VIP是做爲資源註冊到OCR，因此任何VIP的改動都需調用相關命令進行處理。
以上處理都須要在集羣資源停掉的基礎上操做。
如下是修改先後的public/pricate/vip

Public IP 10.194.129.145/146 –> 10.194.128.145/146
Privite IP 10.10.10.145/146 –> 10.10.1.145/146
Virtual IP 10.194.129.147/148 –> 10.194.128.147/148

1.停掉各資源
數據庫正常關庫，其他資源使用crs_stop 中止。
2.從新修改網卡ip/gateway/host文件等,重啓網絡等相關服務
3.利用oifcfg更改public/private ip
查看當前使用

td1-> oifcfg getif
eth1 10.10.10.0 global cluster_interconnect
eth0 10.194.129.0 global public

刪除當前

td1-> oifcfg delif -global eth0
td1-> oifcfg delif -global eth1

從新添加

td1-> oifcfg setif -global eth0/10.194.128.0:public
td1-> oifcfg setif -global eth1/10.10.1.0:cluster_interconnect

4.更新註冊到OCR中的vip配置(root用戶)

[root@td1 ~]# crs_register -update ora.td1.vip -o oi=eth0,ov=10.194.128.147,on=255.255.255.0
[root@td1 ~]# crs_register -update ora.td2.vip -o oi=eth0,ov=10.194.128.148,on=255.255.255.0

或者使用(root用戶)

[root@td1 ~]# srvctl modify nodeapps -n td1 -A 10.194.128.147/255.255.255.0/eth0
[root@td1 ~]# srvctl modify nodeapps -n td2 -A 10.194.128.148/255.255.255.0/eth0

5.若是你使用了ocfs，修改ocfs配置文件(/etc/ocfs/cluster.conf),驗證修改後是否可用
6.修改監聽listener配置文件
7.啓動集羣各節點資源並驗證

td1-> crs_start –all

登錄數據庫，檢驗內鏈接是否生效。

SQL> select * from v$cluster_interconnects;
NAME IP_ADDRESS IS_PUBLIC SOURCE
————— —————- ——— —————————-
eth1 10.10.1.145 NO Oracle Cluster Repository

<三>.集羣中節點的刪除/添加
    同9i的節點刪除/添加相比，10g對節點的添加和刪除相對來講略顯麻煩，但操做起來更加規範。
    由於集羣件的存在，需調用一系列接口命令將資源從OCR中添加/刪除，本文再也不對該案例作詳細描述，具體參見oracle官方聯機文檔RAC部分–Adding and Deleting Nodes and Instances on UNIX-Based Systems.

<四>.升級與遷移
    RAC的遷移與升級並不比單實例複雜多少。對於一個rac新手來講，在思想上也無需以爲這是個很龐雜的事情，固然前提是你有足夠的單實例方面的基礎知識並對此深入理解。
    好比，利用rman備份，咱們能夠方便的將一個運行在單節點的實例遷移到rac環境下。須要作的重點，僅僅是遷移數據庫(你能夠想象成是單實例對單實例)，而後編輯參數文件，添加其餘節點啓動db所必要的redo和undo，並註冊數據庫資源到集羣中以便管理。
    若是你的遷移或升級有停機時間的限制，那大部分狀況下重點的問題並不在於被操做對象是RAC架構，而在於如何制定你的MAA策略。好比你須要運用一些表空間傳輸或者高級複製/流等方面的特性來壓縮停機時間，這也許由於是RAC架構而增長了整個施工的難度，但不少時候問題的重點並不在於此。
    接下來提供一個9I RAC同機靜默升級到 10G RAC的案例,詳細可參見個人一篇blog http://www.easyora.net/blog/9i_rac_upgrade_10g_rac.html

<五>.高可用架構:RAC+DG
    應該說，rac+dg企業級的架構在高可用和災備方面來講仍是有至關大的市場。
    在搭建與管理方面，rac(主)+DG(備)的過程與單實例的主備也無太大異同。須要注意如下方面(但不限於如下方面):
1.log gap的檢測問題
    注意正確配置fal_server與fal_clicent參數，尤爲是對於rac主庫歸檔到各自節點上的狀況下,standby端gap server須要將每一個主庫節點都涵蓋進去。
2.switchover/failover注意事項
    作任何切換的時候，須要將rac端只保留一個alive的實例，其他實例關閉後，切換步驟跟單節點dg基本一致。
3.standby logfile問題
    若是採用LGWR傳輸日誌，須要備庫端添加standby logfile日誌。須要注意添加的standby logfile的thread要與主庫一致。若是你的主庫節點有3個實例，那須要添加3大組與rac主庫相同thread號的備用日誌，每一個thread至少2組日誌便可。

6、RAC監控優化

1.思路及等待事件說明

  鑑於RAC體系的複雜性，RAC的優化比單實例的優化給咱們提出了更高的難度和要求。大部分狀況下，單實例上的優化方法在RAC結構下一樣適用。

  RAC優化的2個核心問題:

(1).減小shared pool的壓力:減小對數據字典的爭用，減小硬解析。

  由於row cache/library cache是全局的，頻繁的數據字典爭用/硬解析在RAC環境下會形成比單實例更嚴重的性能後果。

(2).減小因Cache fusion帶來的全局塊傳輸和爭用

  頻繁的Cache fusion會帶來一系列數據塊上的全局爭用。如何減小邏輯讀，減小數據在實例之間共享傳輸，是RAC體系對應用設計和部署的新要求

Cache fusion性能是影響RAC系統性能的一個極爲重要的方面。Avg global cache cr block receive time和avg global cache current block receive time是cache fusion的兩個重要指標，如下是oracle給出的這兩個指標的閾值狀況:

Name	Lower Bound	Typical	Upper Bound
Avg global cache cr block receive time(ms)	0.3	4	12
Avg global cache current block receive time(ms)	0.3	8	30

RAC下的全局等待事件:

SQL>select * from v$event_name where NAME like ‘gc%’ and WAIT_CLASS=’Cluster’;

10G R2下有40多個非空閒的全局等待時間，最多見的值得引發注意的等待事件以下：

gc current/cr request

該等待事件表示資源從遠程實例讀取到本地實例所花費的時間。出現該事件並不能說明什麼問題，若是等待時間過長，可能表示內聯網絡存在問題或者有嚴重的塊爭用。

gc buffer busy

buffer busy waits在全局上的延伸。出現該等待時間通常多是塊的爭用問題。

Enquenue類

RAC中，常見的Enquenue有enq: HW – contention/ enq: TX - index contention/enq等，在跨節點高併發的insert環境中很容易出現。

  諸如gc current-2way/3way.gc current/cr grant等事件，這些事件只是提供了塊傳輸和消息傳輸方面的細節或是結果，通常狀況下無需太投入關注。

2.性能診斷

  性能上的調整很難給出一個定式，但指導思想上能夠實現很大方面的統一。

  AWR/ASH等報告能夠做爲RAC系統中一個強有力的性能採集和診斷工具。同單實例的報告相比，AWR中的RAC Statistics部分給咱們提供了詳細的GES、GCS性能採樣，結合全局等待事件，定位集羣問題上的症狀。

在RAC結構下，Segment Statistics部分是咱們更加須要注意的地方。若是你仍是習慣使用STATSPACK來進行性能採集，建議至少將收集級別設置爲7。該部分爲咱們提供了詳細的Segment級別的活動狀況，有助於咱們定位全局的HOT table /HOT index，分析全局資源排隊爭用的根源。

  要重視DBA_HIS開頭的一系列視圖的做用，這將幫咱們將問題定位的更加細化，甚至定位到SQL級別。糟糕的SQL效率拖垮系統性能的案例比比皆是，這在RAC中每每更加常見。dba_hist_active_sess_history 能夠做爲很好的切入點，例如經過關聯dba_hist_sqltext得到執行文本，經過關聯dba_hist_sql_plan得到執行計劃樹等，有時候將直接找到形成等待事件的元兇。

RAC中常見的爭用和解決方法：

① Sequence and index contention

  Sequence是RAC中容易引發爭用的一個地方,尤爲是以sequence做索引，在高併發的多節點insert狀況下極易引發索引塊的爭用以及CR副本的跨實例傳輸。
須要儘可能增大Sequence的cache值並設置序列爲noorder。

② undo block considerations

  RAC下CR的構造比單實例成本要高，若是一個block中的活動事務分佈在幾個實例上，須要將幾個實例上的undo合併構造所須要的CR，尤爲是高併發的有索引鍵的插入，容易形成undo block的爭用。

儘可能使用小事務處理。

③ HW considerations

  跨節點的高併發insert會形成高水位線的爭用，採用更大的extent/採用ASSM和分區技術能減緩這一爭用。

④ Hot Block

  全局熱點塊問題對RAC系統的影響巨大，儘可能減小塊跨實例的併發更改,適當採用分區能夠緩解該爭用。

  一個良好的應用設計是RAC發揮功力的重要前提，根據不一樣的節點部署不一樣的應用，能有效的減小全局資源的爭用，對RAC性能的穩定也至關重要。

---

---

 

集羣概念介紹

集羣術語須知

服務硬件：指提供計算服務的硬件，好比 PC 機、PC 服務器。

服務實體：服務實體一般指服務軟體和服務硬體。

節點（node）：運行 Heartbeat 進程的一個獨立主機稱爲節點，節點是 HA 的核心組成部分，每一個節點上運行着操做系統和Heartbeat 軟件服務。

資源（resource）：資源是一個節點能夠控制的實體，當節點發生故障時，這些資源可以被其餘節點接管。如： 磁盤分區、文件系統、IP 地址、應用程序服務、共享存儲

事件（event）：事件也就是集羣中可能發生的事情，例如節點系統故障、網絡連通故障、網卡故障和應用程序故障等。這些事件都會致使節點的資源發生轉移，HA 的測試也是基於這些事件進行的。

什麼是集羣

集羣（cluster）就是一組計算機，它們做爲一個總體向用戶提供一組網絡資源，這些單個的計算機系統就是集羣的節點（node）。集羣提供瞭如下關鍵的特性。

(一) 可擴展性。集羣的性能不限於單一的服務實體，新的服務實體能夠動態的加入到集羣，從而加強集羣的性能。

(二) 高可用性。集羣經過服務實體冗餘使客戶端免於輕易遭遇到「out of service」警告。當一臺節點服務器發生故障的時候，這臺服務器上所運行的應用程序將在另外一節點服務器上被自動接管。消除單點故障對於加強數據可用性、可達性和可靠性是很是重要的。

(三) 負載均衡。負載均衡能把任務比較均勻的分佈到集羣環境下的計算和網絡資源，以便提升數據吞吐量。

(四) 錯誤恢復。若是集羣中的某一臺服務器因爲故障或者維護須要而沒法使用，資源和應用程序將轉移到可用的集羣節點上。這種因爲某個節點中的資源不能工做，另外一個可用節點中的資源可以透明的接管並繼續完成任務的過程叫作錯誤恢復。

分佈式與集羣的聯繫與區別以下：

(一) 分佈式是指將不一樣的業務分佈在不一樣的地方。

(二) 而集羣指的是將幾臺服務器集中在一塊兒，實現同一業務。

(三) 分佈式的每個節點，均可以作集羣，而集羣並不必定就是分佈式的。而分佈式，從狹義上理解，也與集羣差很少，可是它的組織比較鬆散，不像集羣，有必定組織性，一臺服務器宕了，其餘的服務器能夠頂上來。分佈式的每個節點，都完成不一樣的業務，一個節點宕了，這個業務就不可訪問了。

集羣主要分紅三大類：

HA：高可用集羣（High Availability Cluster）。

LBC：負載均衡集羣/負載均衡系統（Load Balance Cluster）

HPC：科學計算集羣（High Performance Computing Cluster）/高性能計算（High Performance Computing）集羣。

爲何搭建數據庫集羣

隨着經濟的高速發展，企業規模的迅猛擴張，企業用戶的數量、數據量的爆炸式增加，對數據庫提出了嚴峻的考驗。對於全部的數據庫而言，除了記錄正確的處理結果以外，還面臨着如下幾方面的挑戰。

• l  如何提升處理速度，實現數據庫的均衡負載。
• l  如何保證數據庫的可用性、數據安全性、以及如何實現數據集羣可擴性。
• l  怎麼綜合解決這些問題成爲衆多企業關注的焦點。

在數據庫上，組建集羣也是一樣的道理，主要有如下幾個緣由：

(一) 伴隨着企業的成長，業務量提升，數據庫的訪問量和數據量快速增加，其處理能力和計算速度也相應增大，使得單一的設備根本沒法承擔。

(二) 在以上狀況下，若扔掉現有設備，作大量的硬件升級，勢必形成現有資源的浪費，並且下一次業務量提高時，又將面臨再一次硬件升級的高額投入。因而，人們但願經過幾箇中小型服務器組建集羣，實現數據庫的負載均衡及持續擴展；在須要更高數據庫處理速度時，只要簡單的增長數據庫服務器就能夠獲得擴展。

(三) 數據庫做爲信息系統的核心，起着很是重要的做用，單一設備根本沒法保證系統的下持續運行，若發生系統故障，將嚴重影響系統的正常運行，甚至帶來巨大的經濟損失。因而，人們但願經過組建數據庫集羣，實現數據庫的高可用，當某節點發生故障時，系統會自動檢測並轉移故障節點的應用，保證數據庫的持續工做。

(四) 企業的數據庫保存着企業的重要信息，一些核心數據甚相當繫着企業的命脈，單一設備根本沒法保證數據庫的安全性，一旦發生丟失，很難再找回來。因而，人們但願經過組建數據庫集羣，實現數據集的冗餘，經過備份數據來保證安全性。

數據庫集羣的分類

數據庫集羣技術是將多臺服務器聯合起來組成集羣來實現綜合性能優於單個大型服務器的技術，這種技術不但能知足應用的須要，並且大幅度的節約了投資成本。數據庫集羣技術分屬兩類體系：基於數據庫引擎的集羣技術和基於數據庫網關（中間件）的集羣技術。在數據庫集羣產品方面，其中主要包括基於數據庫引擎的集羣技術的 Oracle RAC、Microsoft MSCS、IBM DB2UDB、Sybase ASE，以及基於數據庫網關（中間件）的集羣技術的 ICX-UDS 等產品。

通常來說，數據庫集羣軟件側重的方向和試圖解決的問題劃分爲三大類：

• l  負載均衡集羣（Load Balance Cluster，LBC）側重於數據庫的橫向擴展，提高數據庫的性能。
• l  高可用性集羣（High Availability Cluster，HAC）側重保證數據庫應用持續不斷。大部分的數據庫集羣側重與此。
• l  高安全性集羣（High Security Cluster，HSC）側重於容災。

只有 Oracle RAC 能實現以上三方面

可擴展的分佈式數據庫架構

(一) Oracle RAC：

其架構的最大特色是共享存儲架構（Shared-storage），整個 RAC 集羣是創建在一個共享的存儲設備之上的，節點之間採用高速網絡互聯。OracleRAC 提供了很是好的高可用特性，好比負載均衡和應用透明切塊（TAF），其最大的優點在於對應用徹底透明，應用無需修改即可切換到RAC 集羣。可是RAC 的可擴展能力有限，首先由於整個集羣都依賴於底層的共享存儲，因此共享存儲的 I/O 能力和可用性決定了整個集羣的能夠提供的能力，對於 I/O 密集型的應用，這樣的機制決定後續擴容只能是 Scale up（向上擴展）類型，對於硬件成本、開發人員的要求、維護成本都相對比較高。Oracle顯然也意識到了這個問題，在 Oracle 的 MAA（Maximum Availability Architecture）架構中，採用 ASM 來整合多個存儲設備的能力，使得 RAC 底層的共享存儲設備具有線性擴展的能力，整個集羣再也不依賴於大型存儲的處理能力和可用性。

RAC 的另一個問題是，隨着節點數的不斷增長，節點間通訊的成本也會隨之增長，當到某個限度時，增長節點可能不會再帶來性能上的提升，甚至可能形成性能降低。這個問題的主要緣由是 Oracle RAC 對應用透明，應用能夠鏈接集羣中的任意節點進行處理，當不一樣節點上的應用爭用資源時，RAC 節點間的通訊開銷會嚴重影響集羣的處理能力。因此對於使用 ORACLE RAC 有如下兩個建議：

• l  節點間通訊使用高速互聯網絡；
• l  儘量將不一樣的應用分佈在不一樣的節點上。

基於這個緣由，Oracle RAC 一般在 DSS 環境（決策支持系統Decision Support System ，簡稱DSS)中能夠作到很好的擴展性，由於 DSS 環境很容易將不一樣的任務分佈在不一樣計算節點上，而對於 OLTP 應用（On-Line Transaction Processing聯機事務處理系統），Oracle RAC 更多狀況下用來提升可用性，而不是爲了提升擴展性。

(二) MySQL Cluster

MySQL cluster 和 Oracle RAC 徹底不一樣，它採用 無共享架構Shared nothing（shared nothing architecture）。整個集羣由管理節點(ndb_mgmd)，處理節點(mysqld)和存儲節點(ndbd)組 成，不存在一個共享的存儲設備。MySQL cluster 主要利用了 NDB 存儲引擎來實現，NDB 存儲引擎是一個內存式存儲引擎，要求數據必須所有加載到內存之中。數據被自動分佈在集羣中的不一樣存 儲節點上，每一個存儲節點只保存完整數據的一個分片(fragment)。同時，用戶能夠設置同一份數據保存在多個不一樣的存儲節點上，以保證單點故障不會造 成數據丟失。MySQL cluster 主要由 3 各部分組成：

• l  SQL 服務器節點
• l  NDB 數據存儲節點
• l  監控和管理節點

這樣的分層也是與 MySQL 自己把 SQL 處理和存儲分開的架構相關係的。MySQL cluster 的優勢在於其是一個分佈式的數據庫集羣，處理節點和存儲節點均可以線性增長，整個集羣沒有單點故障，可用性和擴展性均可以作到很高，更適合 OLTP 應用。可是它的問題在於：

• l   NDB（「NDB」 是一種「內存中」的存儲引擎，它具備可用性高和數據一致性好的特色。） 存儲引擎必需要求數據所有加載到內存之中，限制比較大，可是目前 NDB 新版本對此作了改進，容許只在內存中加 載索引數據，數據能夠保存在磁盤上。
• l  目前的 MySQL cluster 的性能還不理想，由於數據是按照主鍵 hash 分佈到不一樣的存儲節點上，若是應用不是經過主鍵去獲取數據的話，必須在全部的存儲節點上掃描， 返回結果處處理節點上去處理。並且，寫操做須要同時寫多份數據到不一樣的存儲節點上，對節點間的網絡要求很高。

雖然 MySQL cluster 目前性能還不理想，可是 share nothing 的架構必定是將來的趨勢，Oracle 接手 MySQL以後，也在大力發展 MySQL cluster，我對 MySQL cluster 的前景抱有很大的期待。

(三) 分佈式數據庫架構

MySQL 5 以後纔有了數據表分區功能（Sharding）， Sharding 不是一個某個特定數據庫軟件附屬的功能，而是在具體技術細節之上的抽象處理，是水平擴展(Scale Out，亦或橫向擴展、向外擴展)的解決方案，其主要目的是爲突破單節點數據庫服務器的 I/O 能力限制，解決數據庫擴展性問題。好比 Oracle 的 RAC 是採用共享存儲機制，對於 I/O 密集型的應用，瓶頸很容易落在存儲上，這樣的機制決定後續擴容只能是 Scale Up（向上擴展） 類型，對於硬件成本、開發人員的要求、維護成本都相對比較高。Sharding 基本上是針對開源數據庫的擴展性解決方案，不多有據說商業數據庫進行 Sharding 的。目前業界的趨勢基本上是擁抱 Scale Out，逐漸從 Scale Up 中解放出來。

Sharding 架構的優點在於，集羣擴展能力很強，幾乎能夠作到線性擴展，並且整個集羣的可用性也很高，部分節點故障，不會影響其餘節點提供服務。Sharding 原理簡單，容易實現，是一種很是好的解決數據庫擴展性的方案。Sharding 並非數據庫擴展方案的銀彈，也有其不適合的場景，好比處理事務型的應用它可能會形成應用架構複雜或者限制系統的功能，這也是它的缺陷所在。讀寫分離是架構分佈式系統的一個重要思想。很多系統總體處理能力並不能同業務的增加保持同步，所以勢必會帶來瓶頸，單純的升級硬件並不能一勞永逸。針對業務類型特色，須要從架構模式進行一系列的調整，好比業務模塊的分割，數據庫的拆分等等。集中式和分佈式是兩個對立的模式，不一樣行業的應用特色也決定了架構的思路。如互聯網行業中一些門戶站點，出於技術和成本等方面考慮，更多的採用開源的數據庫產品(如 MYSQL)，因爲大部分是典型的讀多寫少的請求，所以爲 MYSQL 及其複製技術大行其道提供了條件。而相對一些傳統密集交易型的行業，好比電信業、金融業等，考慮到單點處理能力和可靠性、穩定性等問題，可能更多的採用商用數據庫，好比DB2、Oracle 等。就數據庫層面來說，大部分傳統行業核心庫採用集中式的架構思路，採用高配的小型機作主機載體，由於數據庫自己和主機強大的處理能力，數據庫端通常能支撐業務的運轉，所以，Oracle 讀寫分離式的架構相對MYSQL 來說，相對會少。讀寫分離架構利用了數據庫的複製技術，將讀和 寫分佈在不一樣的處理節點上，從而達到提升可用性和擴展性的目的。最一般的作法是利用 MySQL Replication 技術，Master DB 承擔寫操做，將數據變化複製到多臺 Slave DB上，並承擔讀的操做。這種架構適合 read-intensive 類型的應用，經過增長 Slave DB 的數量，讀的性能能夠線性增加。爲了不 Master DB 的單點故障，集羣通常都會採用兩臺 Master DB 作雙機熱備，因此整個集羣的讀和寫的可用性都很是高。除了 MySQL，Oracle 從 11g 開始提供 Active Standby 的功能，也具有了實現讀寫分離架構的基礎。讀寫分離架構的缺陷在於，無論是 Master 仍是 Slave，每一個節點都必須保存完整的數據，如 果在數據量很大的狀況下，集羣的擴展能力仍是受限於單個節點的存儲能力，並且對於 Write-intensive 類型的應用，讀寫分離架構並不適合。

採用 Oracle 讀寫分離的思路，Writer DB 和 Reader DB 採用日誌複製軟件實現實時同步； Writer DB 負責交易相關的實時查詢和事務處理，Reader DB 負責只讀接入，處理一些非實時的交易明細,報表類的彙總查詢等。同時，爲了知足高可用性和擴展性等要求，對讀寫端適當作外延，好比 Writer DB 採用 HA 或者 RAC 的架構模式，目前，除了數據庫廠商的 集羣產品之外，解決數據庫擴展能力的方法主要有兩個：數據分片和讀寫分離。數據分片(Sharding)的原理就是將數據作水平切分，相似於 hash 分區 的原理，經過應用架構解決訪問路由和Reader DB 能夠採用多套，經過負載均衡或者業務分離的方式，有效分擔讀庫的壓力。

對於 Shared-nothing 的數據庫架構模式，核心的一個問題就是讀寫庫的實時同步；另外，雖然 Reader DB只負責業務查詢，但並不表明數據庫在功能上是隻讀的。只讀是從應用角度出發，爲了保證數據一致和衝突考慮，由於查詢業務模塊可能須要涉及一些中間處理，若是須要在數據庫裏面處理(取決與應用需求和設計)，因此Reader DB 在功能上仍然須要可寫。下面談一下數據同步的技術選型問題：

能實現數據實時同步的技術不少，基於 OS 層(例如 VERITAS VVR)，基於存儲複製(中高端存儲大多都支持)，基於應用分發或者基於數據庫層的技術。由於數據同步可能並非單一的 DB 整庫同步，會涉及到業務數據選擇以及多源整合等問題，所以 OS 複製和存儲複製多數狀況並不適合作讀寫分離的技術首選。基於日誌的 Oracle 複製技術，Oracle 自身組件能夠實現，同時也有成熟的商業軟件。選商業的獨立產品仍是 Oracle 自身的組件功能，這取決於多方面的因素。好比團隊的相應技術運維能力、項目投入成本、業務系統的負載程度等。

採用 Oracle 自身組件功能，無外乎 Logical Standby、Stream 以及 11g 的 Physical Standby(Active Data Guard)，對比來講，Stream 最靈活，但最不穩定，11g Physical Standby 支持恢復與只讀並行，但因爲並非日誌的邏輯應用機制，在讀寫分離的場景中最爲侷限。若是技術團隊對相關技術掌握足夠充分，而選型方案的處理能力又能支撐數據同步的要求，採用 Oracle 自身的組件徹底可行。選擇商業化的產品，更多出於穩定性、處理能力等考慮。市面上成熟的 Oracle 複製軟件也無外乎幾種，不管是老牌的 Shareplex，仍是本土 DSG 公司的 RealSync 和九橋公司的 DDS，或是 Oracle 新貴 Goldengate，都是可供選擇的目標。隨着 GoldenGate 被 Oracle 收購和推廣，我的認爲 GoldenGate 在容災、數據分發和同步方面將大行其道。固然，架構好一個可靠的分佈式讀寫分離的系統，還須要應用上作大量設計，不在本文討論範圍內。

(四)  CAP 和 BASE 理論

分佈式領域 CAP 理論：

• l  Consistency(一致性), 數據一致更新，全部數據變更都是同步的
• l  Availability(可用性), 好的響應性能
• l  Partition tolerance(分區容錯性) 可靠性

定理：任何分佈式系統只可同時知足二點，無法三者兼顧。

忠告：架構師不要將精力浪費在如何設計能知足三者的完美分佈式系統，而是應該進行取捨。

關係數據庫的 ACID 模型擁有 高一致性 + 可用性 很難進行分區：

• l  Atomicity 原子性：一個事務中全部操做都必須所有完成，要麼所有不完成。
• l  Consistency 一致性. 在事務開始或結束時，數據庫應該在一致狀態。
• l  Isolation 隔離層. 事務將假定只有它本身在操做數據庫，彼此不知曉。
• l  Durability. 一旦事務完成，就不能返回。

(五)  跨數據庫事務

2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，也就是說傳統關係型數據庫要想實現一個分佈式數據庫集羣很是困難，關係型數據庫的擴展能力十分有限。而近年來不斷髮展壯大的 NoSQL（非關係型的數據庫）運動，就是經過犧牲強一致性，採用 BASE 模型，用最終一致性的思想來設計分佈式系統，從而使得系統能夠達到很高的可用性和擴展性。那麼，有沒有可能實現一套分佈式數據庫集羣，既保證可用性和一致性，又能夠提供很好的擴展能力呢？

BASE 思想的主要實現有按功能劃分數據庫 sharding 碎片BASE 思想主要強調基本的可用性，若是你須要 High 可用性，也就是純粹的高性能，那麼就要以一致性或容錯性爲犧牲，BASE 思想的方案在性能上仍是有潛力可挖的。

• l  共同點：都是關係數據庫 SQL 之外的可選方案，邏輯隨着數據分佈，任何模型均可以本身持久化，將數據處理和數據存儲分離，將讀和寫分離，存儲能夠是異步或同步，取決於對一致性的要求程度。
• l  不一樣點：NOSQL 之類的 Key-Value 存儲產品是和關係數據庫頭碰頭的產品 BOX，能夠適合非 Java 如 PHP RUBY等領域，是一種能夠拿來就用的產品，而領域模型 + 分佈式緩存 + 存儲是一種複雜的架構解決方案，不是產品，但這種方式更靈活，更應該是架構師必須掌握的。

目前，已經有不少分佈式數據庫的產品，可是絕大部分是面向 DSS 類型的應用，由於相比較 OLTP 應用，DSS 應用更容易作到分佈式擴展，好比基於 PostgreSQL 發展的 Greenplum，就很好的解決了可用性和擴展性的問題，而且提供了很強大的並行計算能力。對於 OLTP 應用，業務特色決定其要求：高可用性，一致性， 響應時間短，支持事務和 join 等等。數據庫和 NoSQL當愈來愈多的 NoSQL 產品涌現出來，它們具有不少關係型數據庫所不具有的特性，在可用性和擴展性方面均可以作到很好。

第一，NoSQL 的應用場景很是侷限，某個類型的 NoSQL 僅僅針對特定類型的應用場景而設計。而關係型數據庫則要通用的多，使用 NoSQL 必須搞清楚本身的應用場景是否適合。

第二，利用關係型數據庫配合應用架構， 好比 Sharding 和讀寫分離技術，一樣能夠搭建出具有高可用和擴展性的分佈式數據庫集羣。

第三，關係型數據庫廠商依然很強大，全世界有大量的 用戶，需求必然會推進新的產品問世。

第四，硬件的發展突飛猛進，好比閃存的技術的不斷成熟，將來閃存能夠做爲磁盤與內存之間的 cache，或者完 全替代磁盤。而內存價格愈來愈低，容量愈來愈大，In-memory cache 或 database 的應用愈來愈普遍，能夠給應用帶來數量級的性能提高。數據庫面臨的 IO 問題將被極大改善。

Oracle的三種高可用集羣方案

1 RAC（Real Application Clusters）

                       

多個Oracle服務器組成一個共享的Cache，而這些Oracle服務器共享一個基於網絡的存儲。這個系統能夠容忍單機/或是多機失敗。不過系統內部的多個節點須要高速網絡互連，基本上也就是要所有東西放在在一個機房內，或者說一個數據中心內。若是機房出故障，好比網絡不通，那就壞了。因此僅僅用RAC仍是知足不了通常互聯網公司的重要業務的須要，重要業務須要多機房來容忍單個機房的事故。

2 Data Guard.（最主要的功能是冗災）

 

Data Guard這個方案就適合多機房的。某機房一個production的數據庫，另外其餘機房部署standby的數據庫。Standby數據庫分物理的和邏輯的。物理的standby數據庫主要用於production失敗後作切換。而邏輯的standby數據庫則在平時能夠分擔production數據庫的讀負載。

3 MAA

 

MAA(Maximum Availability Architecture)其實不是獨立的第三種，而是前面兩種的結合，來提供最高的可用性。每一個機房內部署RAC集羣，多個機房間用Data Guard同步。

RAC概述

共享存儲文件系統（NFS），或甚至集羣文件系統（如：OCFS2）主要被用於存儲區域網絡（全部節點直接訪問共享文件系統上存儲器），這就使得節點失效而不影響來自其餘節點對文件系統的訪問，一般，共享磁盤文件系統用於高可用集羣。

Oracle RAC的核心是共享磁盤子系統，集羣中全部節點必須可以訪問全部數據、重作日誌文件、控制文件和參數文件，數據磁盤必須是全局可用的，容許全部節點訪問數據庫，每一個節點有它本身的重作日誌和控制文件，可是其餘節點必須可以訪問它們以便在那個節點出現系統故障時可以恢復。

Oracle RAC 運行於集羣之上，爲 Oracle 數據庫提供了最高級別的可用性、可伸縮性和低成本計算能力。若是集羣內的一個節點發生故障，Oracle 將能夠繼續在其他的節點上運行。Oracle 的主要創新是一項稱爲高速緩存合併的技術。高速緩存合併使得集羣中的節點能夠經過高速集羣互聯高效地同步其內存高速緩存，從而最大限度地低下降磁盤 I/O。高速緩存最重要的優點在於它可以使集羣中全部節點的磁盤共享對全部數據的訪問。數據無需在節點間進行分區。Oracle 是惟一提供具有這一能力的開放系統數據庫的廠商。其它聲稱能夠運行在集羣上的數據庫軟件須要對數據庫數據進行分區，顯得不切實際。企業網格是將來的數據中心，構建於由標準化商用組件構成的大型配置之上，其中包括：處理器、網絡和存儲器。Oracle RAC 的高速緩存合併技術提供了最高等級的可用性和可伸縮性。Oracle 數據庫 10g 和 OracleRAC 10g 顯著下降了運營成本，加強了靈活性，從而賦予了系統更卓越的適應性、前瞻性和靈活性。動態提供節點、存儲器、CPU 和內存能夠在實現所需服務級別的同時，經過提升的利用率不斷下降成本。

RAC 集成集羣件管理

Oracle RAC 10g 在 Oracle 數據庫 10g 運行的全部平臺上提供了一個完整集成的集羣件管理解決方案。這一集羣件功能包括集羣鏈接、消息處理服務和鎖定、集羣控制和恢復，以及一個工做負載管理框架（將在下文探討）。Oracle RAC 10g 的集成集羣件管理具備如下優點：

(一) 成本低。Oracle 免費提供這一功能。

(二) 單一廠商支持。消除了相互推諉的問題。

(三) 安裝、配置和持續維護更簡單。Oracle RAC 10g 集羣件使用標準 Oracle 數據庫管理工具進行安裝、配置和維護。這一過程無須其它的集成步驟。

(四) 全部平臺，質量始終如一。與第三方產品相比，Oracle 對新軟件版本進行了更嚴格的測試。

(五) 全部平臺，功能始終如一。例如，一些第三方集羣件產品限制了集羣內能夠支持的節點的數量。藉助Oracle RAC 10g，全部平臺能夠支持多達 64 個節點。用戶還能夠在全部平臺上得到一致的響應體驗，從而有效解決了高可用性挑戰，包括服務器節點故障、互連故障以及 I/O 隔離現象等。

(六) 支持高級功能。這包括集成監視和通知功能，從而在發生故障時，在數據庫和應用層之間實現快速協調的恢復。

RAC 的體系結構

RAC 是 Oracle 數據庫的一個羣集解決方案，是有着兩個或者兩個以上的數據庫節點協調運做能力的。以下圖所示的 RAC 結構圖：

 

集羣管理器（Cluster Manager）在集羣系統中對其餘各個模塊進行整合，經過高速的內鏈接來提供羣集節點之間的通訊。各節點之間內鏈接使用心跳線互聯，心跳線上的信息功能肯定羣集邏輯上的節點成員信息和節點更新狀況，以及節點在某個時間點的運行狀態，保證羣集系統正常運行。通訊層管理節點之間的通訊。它的職責是配置，互聯羣集中節點信息，在羣集管理器中使用由心跳機制產生的信息，由通訊層負責傳輸，確保信息的正確到達。還有一些羣集監視進程不斷驗證系統的不一樣領域運行情況。例如，心跳監測不斷驗證的心跳機制的運做是否良好。在一個應用環境當中，全部的服務器使用和管理同一個數據庫，目的是分散每一臺服務器的工做量。硬件上至少須要兩臺以上的服務器，並且還須要一個共享存儲設備；同時還須要兩類軟件，一類是集羣軟件，另一類就是 Oracle 數據庫中的 RAC 組件。同時全部服務器上的 OS 都應該是同一類 OS，根據負載均衡的配置策略，當一個客戶端發送請求到某一臺服務的 listener 後，這臺服務器根據負載均衡策略，會把請求發送給本機的 RAC組件處理，也可能會發送給另一臺服務器的 RAC 組件處理，處理完請求後，RAC 會經過羣集軟件來訪問共享存儲設備。邏輯結構上看，每個參加羣集的節點有一個獨立的實例，這些實例訪問同一個數據庫。節點之間經過集羣軟件的通訊層（Communication Layer）來進行通訊。同時爲了減小 I/O 的消耗，存在一個全局緩存服務，所以每個數據庫的實例，都保留了一份相同的數據庫 cache。RAC 中的特色以下：

• l   每個節點的實例都有本身的 SGA；
• l   每個節點的實例都有本身的後臺進程
• l   每個節點的實力都有本身的 redo logs
• l   每個節點的實例都有本身的 undo 表空間
• l   全部節點都共享一份 datafiles 和 controlfiles

RAC 的結構組成和機制

在 Oracle9i 以前，RAC 稱爲 OPS（Oracle Parallel Server）。RAC 與 OPS 之間的一個較大區別是，RAC 採用了Cache Fusion（高緩存合併）技術，節點已經取出的數據塊更新後沒有寫入磁盤前，能夠被另一個節點更新，而後以最後的版本寫入磁盤。在 OPS 中，節點間的數據請求須要先將數據寫入磁盤，而後發出請求的節點才能夠讀取該數據。使用 Cache Fusion 時，RAC 的各個節點間數據緩衝區經過高速、低延遲的內部網絡進行數據塊的傳輸。下圖是一個典型的 RAC 對外服務的示意圖，一個 Oracle RAC Cluster 包含了以下的部分

 

1. 集羣的節點（Cluster node）——2 個到 N 個節點或者主機運行 Oracle Database Server。
2. 私有網絡（Network Interconnect）——RAC 之間須要一個高速互聯的私有網絡來處理通訊和 Cache Fusion。
3. 共享存儲（shared Storage）——RAC 須要共享存儲設備讓全部的節點均可以訪問數據文件。
4. 對外服務的網絡（Production Network）——RAC 對外服務的網絡。客戶端和應用都經過這個網絡來訪問。

RAC 後臺進程

Oracle RAC 有一些本身獨特的後臺進程，在單一實例中不發揮配置做用。以下圖所示，定義了一些 RAC 運行的後臺進程。這些後臺進程的功能描述以下。

 

（1）LMS（Global cache service processes 全局緩存服務進程）進程主要用來管理集羣內數據塊的訪問，並在不一樣實例的 Buffer Cache 中傳輸數據塊鏡像。直接從控制的實例的緩存複製數據塊，而後發送一個副本到請求的實例上。並保證在全部實例的 Buffer Cache 中一個數據塊的鏡像只能出現一次。LMS 進程靠着在實例中傳遞消息來協調數據塊的訪問，當一個實例請求數據塊時，該實例的 LMD 進程發出一個數據塊資源的請求，該請求指向主數據塊的實例的 LMD 進程，主實例的 LMD 進程和正在使用的實例的 LMD 進程釋放該資源，這時擁有該資源的實例的 LMS 進程會建立一個數據塊鏡像的一致性讀而後把該數據塊傳遞到請求該資源的實例的BUFFER CACHE 中。LMS 進程保證了在每一時刻只能容許一個實例去更新數據塊，並負責保持該數據塊的鏡像記錄（包含更新數據塊的狀態 FLAG)。RAC 提供了 10 個 LMS 進程（0~9），該進程數量隨着節點間的消息傳遞的數據的增長而增長。（2）LMON（Lock Monitor Process，鎖監控進程）是全局隊列服務監控器，各個實例的 LMON 進程會按期通訊，以檢查集羣中各個節點的健康情況，當某個節點出現故障時，負責集羣重構、GRD 恢復等操做，它提供的服務叫作 Cluster Group Service（CGS）。

LMON 主要藉助兩種心跳機制來完成健康檢查。

(一) 節點間的網絡心跳（Network Heartbeat）：能夠想象成節點間定時的發送 ping 包檢測節點狀態，若是能在規定時間內收到迴應，就認爲對方狀態正常。

(二) 經過控制文件的磁盤心跳（controlfile heartbeat）：每一個節點的 CKPT 進程每隔 3 秒鐘更新一次控制文件的數據塊，這個數據塊叫作 Checkpoint Progress Record，控制文件是共享的，因此實例間能夠互相檢查對方是否及時更新來判斷。

(三) LMD（the global enqueue service daemon，鎖管理守護進程）是一個後臺進程，也被稱爲全局的隊列服務守護進程，由於負責對資源的管理要求來控制訪問塊和全局隊列。在每個實例的內部，LMD 進程管理輸入的遠程資源請求（即來自集羣中其餘實例的鎖請求）。此外，它還負責死鎖檢查和監控轉換超時。

(四) LCK（the lock process，鎖進程）管理非緩存融合，鎖請求是本地的資源請求。LCK 進程管理共享資源的實例的資源請求和跨實例調用操做。在恢復過程當中它創建一個無效鎖元素的列表，並驗證鎖的元素。因爲處理過程當中的 LMS 鎖管理的首要職能，只有一個單一的 LCK 進程存在每一個實例中。

(五) DIAG（the diagnosability daemon，診斷守護進程）負責捕獲 RAC 環境中進程失敗的相關信息。並將跟蹤信息寫出用於失敗分析，DIAG 產生的信息在與 Oracle Support 技術合做來尋找致使失敗的緣由方面是很是有用的。每一個實例僅須要一個 DIAG 進程。

(六) GSD（the global service daemon，全局服務進程）與 RAC 的管理工具 dbca、srvctl、oem 進行交互，用來完成實例的啓動關閉等管理事務。爲了保證這些管理工具運行正常必須在全部的節點上先start gsd，而且一個 GSD 進程支持在一個節點的多個 rac.gsd 進程位ORACLEHOME/bin目錄下，其log文件爲ORACLEHOME/bin目錄下，其log文件爲ORACLE_HOME/srvm/log/gsdaemon.log。GCS 和 GES 兩個進程負責經過全局資源目錄（Global Resource Directory GRD）維護每一個數據的文件和緩存塊的狀態信息。當某個實例訪問數據並緩存了數據以後，集羣中的其餘實例也會得到一個對應的塊鏡像，這樣其餘實例在訪問這些數據是就不須要再去讀盤了，而是直接讀取 SGA 中的緩存。GRD 存在於每一個活動的 instance 的內存結構中，這個特色形成 RAC 環境的 SGA 相對於單實例數據庫系統的 SGA 要大。其餘的進程和內存結構都跟單實例數據庫差異不大。

RAC 共享存儲

RAC 須要有共享存儲，獨立於實例以外的信息，如上面提到的ocr 和 votedisk 以及數據文件都存放在這個共享存儲裏的。有OCFS、OCFS二、RAW、NFS、ASM 等這樣的一些存儲方式。OCFS（Oracle Cluster File System） 和 OCFS2 就是一個文件系統而已，和 NFS 同樣，提供一種集羣環境中的共享存儲的文件系統。RAW 裸設備也是一種存儲方式，是 oracle11g 以前的版本中 RAC 支持的存儲方式，在 Oralce9i 以前，OPS/RAC的支持只能使用這樣的方式，也就是把共享存儲映射到 RAW Device，而後把 Oracle 須要的數據選擇 RAW device存儲，可是 RAW 相對於文件系統來講不直觀，不便於管理，並且 RAW Device 有數量的限制，RAW 顯然須要有新的方案來代替，這樣就有了 OCFS 這樣的文件系統。固然，這只是 Oracle 本身的實現的集文件系統而已，還有其餘廠商提供的文件系統能夠做爲存儲的選擇方案。ASM 只是數據庫存儲的方案而已，並非 cluster 的方案，因此這裏 ASM 應該是區別於 RAW 和 OCFS/OCFS2同一級別的概念，RAW 和 OCFS/OCFS2 不只能夠做爲數據庫存儲的方案，同時也能夠做爲 Clusterware 裏的存儲方案，是 CRS 裏須要的 storage，而 ASM 僅做爲數據庫的存儲而已，嚴格來講僅是 RAC 中的一個節點應用（nodeapps）。ASM 對於 clusterware 安裝時須要的 ocr 和 votedisk 這兩項還不支持，畢竟 ASM 自己就須要一個實例，而 CRS 是徹底在架構以外的，這也就是爲何使用了 ASM 的方案，卻總還要加上 OCFS/OCFS2 和 RAW 其中的一個緣由。各類 RAC 共享存儲方式的對好比下：

1. 集羣文件系統——支持 windows 和 Linux 的 OCFS/OCFS2
2. AIX 下的 GPFS 等方式——優勢是管理方便，表示也很直觀，但缺點是基於文件系統管理軟件，又要通過 OS 的 cache 處理，性能上和穩定性上都有欠缺，因此不適合在生產環境下使用。能夠支持 CRS 集羣軟件文件和數據庫文件。
3. RAW 裸設備方式——經過硬件支持的共享存儲系統，直接用 RAW 設備存儲，能夠支持集羣軟件文件和數據庫文件。
4. 網絡文件系統（NFS）——經過 NFS 實現共享存儲，不過須要通過 Oracle 認證的 NFS 才行，能夠支持CRS 集羣軟件文件和數據庫文件。
5. ASM——集合 RAW 方式 I/O 高性能和集羣文件系統易管理等優勢，Oracle10g 下推出的共享存儲方式，可是自己 ASM 就是須要 Oracle 的實例支持，因此 ASM 僅支持數據庫文件，而不支持 CRS 文件。

RAC 數據庫和單實例數據庫的區別

爲了讓 RAC 中的全部實例可以訪問數據庫，全部的 datafiles、control files、PFILE/Spfile 和 redo log files 必須保存在共享磁盤上，而且要都能被全部節點同時訪問，就涉及到裸設備和集羣文件系統等。RAC database 在結構上與單實例的不一樣之處：至少爲每一個實例多配置一個 redo 線程，好比：兩個實例組成的集羣至少要 4 個 redo log group。每一個實例兩個 redo group。另外要爲每個實例準備一個 UNDO 表空間。

一、redo 和 undo，每一個實例在作數據庫的修改時誰用誰的 redo 和 undo 段，各自鎖定本身修改的數據，把不一樣實例的操做相對的獨立開就避免了數據不一致。後面就要考慮備份或者恢復時 redo log 和歸檔日誌在這種狀況下的特殊考慮了。

二、內存和進程各個節點的實例都有本身的內存結構和進程結構.各節點之間結構是基本相同的.經過 Cache Fusion（緩存融合）技術，RAC 在各個節點之間同步 SGA 中的緩存信息達到提升訪問速度的效果也保證了一致性。

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 進程異常，系統會當即重啓。

注意：

一、Voting Disk 和 OCR 必須保存在存儲設備上供各個節點訪問。

二、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

集羣的網絡鏈接

1、專用網絡

      每一個集羣節點經過專用高速網絡鏈接到全部其餘節點，這種專用高速網絡也稱爲集羣互聯或高速互聯 (HSI)。Oracle 的 Cache Fusion 技術使用這種網絡將每一個主機的物理內存 (RAM) 有效地組合成一個高速緩存。 OracleCache Fusion 經過在專用網絡上傳輸某個 Oracle 實例高速緩存中存儲的數據容許其餘任何實例訪問這些數據。它還經過在集羣節點中傳輸鎖定和其餘同步信息保持數據完整性和高速緩存一致性。專用網絡一般是用千兆以太網構建的，可是對於高容量的環境，不少廠商提供了專門爲 Oracle RAC 設計的低延遲、高帶寬的專有解決方案。 Linux 還提供一種將多個物理 NIC 綁定爲一個虛擬 NIC 的方法（此處不涉及）來增長帶寬和提升可用性。

2、公共網絡

     爲維持高可用性，爲每一個集羣節點分配了一個虛擬 IP 地址 (VIP)。 若是主機發生故障，則能夠將故障節點的 IP 地址從新分配給一個可用節點，從而容許應用程序經過相同的 IP 地址繼續訪問數據庫。

3、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 日誌位置

ORACRSHOME/log/hostname/racg/這裏面放的是nodeapp的日誌，包括ONS和VIP，好比：ora.Rac1.ons.Log工具執行日誌：ORACRSHOME/log/hostname/racg/這裏面放的是nodeapp的日誌，包括ONS和VIP，好比：ora.Rac1.ons.Log工具執行日誌：ORA_CRS_HOME/log/hostname/client/

Clusterware 提供了許多命令行工具 好比 ocrcheck, ocrconfig,ocrdump,oifcfg 和 clscfg, 這些工具產生的日誌就放在這個目錄下，還有ORACLEHOME/log/hostname/client/和ORACLEHOME/log/hostname/client/和ORACLE_HOME/log/hostname/racg 也有相關的日誌。

Cache Fusion 原理

      前面已經介紹了 RAC 的後臺進程，爲了更深刻的瞭解這些後臺進程的工做原理，先了解一下 RAC 中多節點對共享數據文件訪問的管理是如何進行的。要了解 RAC 工做原理的中心，須要知道 Cache Fusion 這個重要的概念，要發揮 Cache Fusion 的做用，要有一個前提條件，那就是互聯網絡的速度要比訪問磁盤的速度要快。不然，沒有引入 Cache Fusion 的意義。而事實上，如今 100MB 的互聯網都很常見。

什麼是 Cache Fusion？

       Cache Fusion 就是經過互聯網絡（高速的 Private interconnect）在集羣內各節點的 SGA 之間進行塊傳遞，這是RAC最核心的工做機制，他把全部實例的SGA虛擬成一個大的SGA區，每當不一樣的實例請求相同的數據塊時，這個數據塊就經過 Private interconnect 在實例間進行傳遞。以免首先將塊推送到磁盤，而後再從新讀入其餘實例的緩存中這樣一種低效的實現方式(OPS 的實現)。當一個塊被讀入 RAC 環境中某個實例的緩存時，該塊會被賦予一個鎖資源（與行級鎖不一樣），以確保其餘實例知道該塊正在被使用。以後，若是另外一個實例請求該塊的一個副本，而該塊已經處於前一個實例的緩存內，那麼該塊會經過互聯網絡直接被傳遞到另外一個實例的 SGA。若是內存中的塊已經被改變，但改變還沒有提交，那麼將會傳遞一個 CR 副本。這就意味着只要可能，數據塊無需寫回磁盤便可在各實例的緩存之間移動，從而避免了同步多實例的緩存所花費的額外 I/O。很明顯，不一樣的實例緩存的數據能夠是不一樣的，也就是在一個實例要訪問特定塊以前，而它又從未訪問過這個塊，那麼它要麼從其餘實例 cache fusion 過來，或者從磁盤中讀入。GCS（Global Cache Service，全局內存服務）和 GES（Global EnquenceService，全局隊列服務）進程管理使用集羣節點之間的數據塊同步互聯。

這裏仍是有一些問題須要思考的：

1. 在全部實例都未讀取該塊，而第一個實例讀取時，是怎麼加的鎖，加的什麼鎖？若是此時有另外一個實例也要讀這個塊，幾乎是同時的，那麼 Oracle 如何來仲裁，如何讓其中一個讀取，而另外一個再從前者的緩存中經過 cache 來獲得？
2. 若是一個塊已經被其餘實例讀入，那麼本實例如何判斷它的存在？
3. 若是某個實例改變了這個數據塊，是否會將改變傳遞到其餘實例，或者說其餘實例是否會知道並從新更新狀態？
4. 若是一個實例要 swapout 某個塊，而同時其餘實例也有這個塊的緩存，修改過的和未修改過的，本實例修改的和其餘實例修改的，如何操做? truncate 一張表，drop 一張表... 和單實例有何不一樣？
5. 應該如何設計應用，以使 RAC 真正發揮做用，而不是引入競爭，致使系統被削弱？
6. RAC 下鎖的實現。

      鎖是在各實例的 SGA 中保留的資源，一般被用於控制對數據庫塊的訪問。每一個實例一般會保留或控制必定數量與塊範圍相關的鎖。當一個實例請求一個塊時，該塊必須得到一個鎖，而且鎖必須來自當前控制這些鎖的實例。也就是鎖被分佈在不一樣的實例上。而要得到特定的鎖要從不一樣的實例上去得到。可是從這個過程來看這些鎖不是固定在某個實例上的，而是根據鎖的請求頻率會被調整到使用最頻繁的實例上，從而提升效率。要實現這些資源的分配和重分配、控制，這是很耗用資源的。這也決定了 RAC 的應用設計要求比較高。假設某個實例崩潰或者某個實例加入，那麼這裏要有一個比較長的再分配資源和處理過程。在都正常運行的狀況下會從新分配，以更加有效的使用資源；在實例推出或加入時也會從新分配。在 alert 文件中能夠看到這些信息。而 Cache Fusion 及其餘資源的分配控制，要求有一個快速的互聯網絡，因此要關注與互聯網絡上消息相關的度量，以測試互聯網絡的通訊量和相應時間。對於前面的一些問題，能夠結合另外的概念來學習，它們是全局緩存服務和全局隊列服務。

      全局緩存服務(GCS):要和 Cache Fusion 結合在一塊兒來理解。全局緩存要涉及到數據塊。全局緩存服務負責維護該全局緩衝存儲區內的緩存一致性，確保一個實例在任什麼時候刻想修改一個數據塊時，均可得到一個全局鎖資源，從而避免另外一個實例同時修改該塊的可能性。進行修改的實例將擁有塊的當前版本（包括已提交的和未提交的事物）以及塊的前象(post image)。若是另外一個實例也請求該塊，那麼全局緩存服務要負責跟蹤擁有該塊的實例、擁有塊的版本是什麼，以及塊處於何種模式。LMS 進程是全局緩存服務的關鍵組成部分。

猜測：Oracle 目前的 cache fusion 是在其餘實例訪問時會將塊傳輸過去再構建一個塊在那個實例的 SGA 中，這個主要的緣由多是 interconnect 之間的訪問仍是從本地內存中訪問更快，從而讓 Oracle 再次訪問時能夠從本地內存快速獲取。可是這也有麻煩的地方，由於在多個節點中會有數據塊的多個 copy，這樣在管理上的消耗是很可觀的，Oracle 是否會有更好的解決方案出如今後續版本中？若是 interconnect 速度容許的話...）

全局隊列服務(GES)：主要負責維護字典緩存和庫緩存內的一致性。字典緩存是實例的 SGA 內所存儲的對數據字典信息的緩存，用於高速訪問。因爲該字典信息存儲在內存中，於是在某個節點上對字典進行的修改（如DDL)必須當即被傳播至全部節點上的字典緩存。GES 負責處理上述狀況，並消除實例間出現的差別。處於一樣的緣由，爲了分析影響這些對象的 SQL 語句，數據庫內對象上的庫緩存鎖會被去掉。這些鎖必須在實例間進行維護，而全局隊列服務必須確保請求訪問相同對象的多個實例間不會出現死鎖。LMON、LCK 和 LMD 進程聯合工做來實現全局隊列服務的功能。GES 是除了數據塊自己的維護和管理（由 GCS 完成）以外，在 RAC 環境中調節節點間其餘資源的重要服務。

SQL> select * from gv$sysstat where name like 'gcs %'

                      

這裏能夠看到 gcs 和 ges 消息的發送個數。（若是沒有使用 DBCA 來建立數據庫，那麼要 SYSDBA 權限來運行CATCLUST.SQL 腳原本建立 RAC 相關的視圖和表）

什麼是高可用

      Oracle failsafe、Data Guard 和 RAC 均爲 ORACLE 公司提供的高可靠性（HA）解決方案。然而之三者之間卻存在着很大區別。HA 是 High Availability 的首字母組合，翻譯過來，能夠叫作高可用，或高可用性，高可用（環境）。我以爲應該說 HA 是一個觀念而不是一項或一系列具體技術，就象網格同樣。做過系統方案就知道了，評價系統的性能當中就有一項高可用。也就是 OS 一級的雙機熱備。RAC 是 real application cluster 的簡稱，它是在多個主機上運行一個數據庫的技術，便是一個 db 多個 instance。它的好處是 能夠由多個性能較差的機器構建出一個總體性能很好的集羣，而且實現了負載均衡，那麼當一個節點出現故障時，其上的服務會自動轉到另外的節點去執行，用戶甚 至感受不到什麼。

FAILSAFE 和 RAC 的區別

一、    操做系統：

failsafe 系統侷限於 WINDOWS 平臺，必須配合 MSCS（microsoft cluster server），而 RAC 最先是在 UNIX 平臺推出的，目前已擴展至 LINUX 和 WINDOWS 平臺，經過 OSD（operating system dependent）與系統交互。對於高端的 RAC 應用，UNIX 依然是首選的平臺。

二、    系統結構：

FAILSAFE 採用的是 SHARE NOTHING 結構，即採用若干臺服務器組成集羣，共同鏈接到一個共享磁盤系統，在同一時刻，只有一臺服務器可以訪問共享磁盤，可以對外提供服務。只要當此服務器失效時，纔有另外一臺接管共享磁盤。RAC 則是採用 SHARE EVERYTHING，組成集羣的每一臺服務器均可以訪問共享磁盤，都能對外提供服務。也就是說 FAILSAFE 只能利用一臺服務器資源，RAC 能夠並行利用多臺服務器資源。

三、    運行機理：

組成 FAILSAFE 集羣的每臺 SERVER 有獨立的 IP，整個集羣又有一個 IP，另外還爲 FAILSAFE GROUP 分配一個單獨的 IP（後兩個 IP 爲虛擬 IP，對於客戶來講，只需知道集羣 IP，就能夠透明訪問數據庫）。工做期間，只有一臺服務器（preferred or owner or manager）對外提供服務，其他服務器(operator)成待命狀，當前者失效時，另外一服務器就會接管前者，包括FAILSAFE GROUP IP與CLUSTER IP，同時FAILSAFE會啓動上面的DATABASE SERVICE，LISTENER 和其餘服務。客戶只要從新鏈接便可，不須要作任何改動。對於 RAC 組成的集羣，每臺服務器都分別有自已的 IP，INSTANCE 等，能夠單獨對外提供服務，只不過它們都是操做位於共享磁盤上的同一個數據庫。當某臺服務器失效後，用戶只要修改網絡配置，如（TNSNAMES。ORA），便可從新鏈接到仍在正常運行的服務器上。但和 TAF 結合使用時，甚至網絡也可配置成透明的。

四、    集羣容量：

前者一般爲兩臺，後者在一些平臺上能擴展至 8 臺。

五、    分區：

FAILSAFE 數據庫所在的磁盤必須是 NTFS 格式的，RAC 則相對靈活，一般要求是 RAW，然而若干 OS 已操做出了 CLUSTER 文件系統能夠供 RAC 直接使用。綜上所述，FAILSAFE 比較適合一個可靠性要求很高，應用相對較小，對高性能要求相對不高的系統，而 RAC則更適合可靠性、擴展性、性能要求都相對較高的較大型的應用。

RAC 和 OPS 區別

RAC 是 OPS 的後繼版本，繼承了 OPS 的概念，可是 RAC 是全新的，CACHE 機制和 OPS 徹底不一樣。RAC 解決了 OPS 中 2 個節點同時寫同一個 BLOCK 引發的衝突問題。 從產品上來講 RAC 和 OPS 是徹底不一樣的產品，可是咱們能夠認爲是相同產品的不一樣版本

雙機熱備、RAC 和 Data  Guard的區別

Data Guard 是 Oracle 的遠程複製技術，它有物理和邏輯之分，可是總的來講，它須要在異地有一套獨立的系統，這是兩套硬件配置能夠不一樣的系統，可是這兩套系統的軟件結構保持一致，包括軟件的版本，目錄存儲結構，以及數據的同步（其實也不是實時同步的），這兩套系統之間只要網絡是通的就能夠了，是一種異地容災的解決方案。而對於 RAC，則是本地的高可用集羣，每一個節點用來分擔不用或相同的應用，以解決運算效率低下，單節點故障這樣的問題，它是幾臺硬件相同或不相同的服務器，加一個 SAN（共享的存儲區域）來構成的。Oracle 高可用性產品比較見下表：

 

節點間的通訊（Interconnect）

一般在 RAC 環境下，在公用網絡的基礎上，須要配置兩條專用的網絡用於節點間的互聯，在 HACMP/ES 資源的定義中，這兩條專用的網絡應該被定義爲"private" 。在實例啓動的過程當中，RAC 會自動識別和使用這兩條專用的網絡，而且若是存在公用"public" 的網絡，RAC 會再識別一條公用網絡。當 RAC 識別到多條網絡時，RAC會使用 TNFF (Transparent Network Failvoer Failback) 功能，在 TNFF 下全部的節點間通訊都經過第一條專用的網絡進行，第二條( 或第三條等) 做爲在第一條專用的網絡失效後的備份。RAC 節點間通訊以下圖所示。

 

      CLUSTER_INTERCONNECTS 是在 Oracle RAC 中的一個可選的初始化(init.ora) 參數。此參數能夠指定使用哪一條網絡用於節點間互聯通訊，若是指定多條網絡，RAC 會在這些網絡上自動進行負載均衡。然而，當CLUSTER_INTERCONNECTS 設置時，TNFF 不起做用，這將下降 RAC 的可用性，任何一條節點間互聯網絡的失效，都會形成 RAC 一個或多個節點的失效。ORACLE RAC 用於 INTERCONNECT 的內網卡的物理鏈接方式的選擇：採用交換機鏈接或是網線直連。直連的弊端是，一旦一個節點機的內網卡出現故障，oracle 從 OS 獲得兩個節點的網卡狀態都是不正常的，於是會致使兩個實例都宕掉。在 INTERCONNECT 線路出現問題的時候，oracle 通常狀況下會啓動一個競爭機制來決定哪一個實例宕掉，若是宕掉的實例正好是好的實例的話， 這樣就會致使兩個實例都宕掉。在 9i 中，oracle 在啓動競爭機制以前，會先等待一段時間，等待 OS 將網絡的狀態發給 oracle，若是在超時以前，oracle 得到哪一個實例的網卡是 down 的話，則將該實例宕掉，這樣的話，則能夠保留正常的那個實例繼續服務，不然仍是進入競爭機制。

綜上所述節點間通訊分爲兩種狀況：

 是接在交換機上面，此時通常狀況下，是會保證正常的實例繼續服務的，但有的時候若是 os 來不及將網卡狀態送到 oracle 時，也是有可能會致使兩個節點都宕掉的。

 若是是直連的話，則會致使兩個實例都宕掉。

CSS 心跳

OCSSD 這個進程是 Clusterware 最關鍵的進程，若是這個進程出現異常，會致使系統重啓，這個進程提供CSS(Cluster Synchronization Service)服務。 CSS 服務經過多種心跳機制實時監控集羣狀態，提供腦裂保護等基礎集羣服務功能。

CSS 服務有 2 種心跳機制： 一種是經過私有網絡的 Network Heartbeat，另外一種是經過 Voting Disk 的 DiskHeartbeat。這 2 種心跳都有最大延時，對於 Disk Heartbeat，這個延時叫做 IOT (I/O Timeout);對於 Network Heartbeat, 這個延時叫 MC(Misscount)。這 2 個參數都以秒爲單位，缺省時 IOT 大於 MC，在默認狀況下，這 2 個參數是 Oracle自動斷定的，而且不建議調整。能夠經過以下命令來查看參數值：

$crsctl get css disktimeout

$crsctl get css misscount

Oracle RAC 節點間使用的通訊協議見下表。

 

鎖

LOCK（鎖）是用來控制併發的數據結構，若是有兩個進程同時修改同一個數據， 爲了防止出現混亂和意外，用鎖來控制訪問數據的次序。有鎖的能夠先訪問，另一個進程要等到第一個釋放了鎖，才能擁有鎖，繼續訪問。整體來講,RAC 裏面的鎖分兩種， 一種是本地主機的進程之間的鎖，另一種是不一樣主機的進程之間的鎖。本地鎖的機制有兩類，一類叫作 lock（鎖），另一類叫作 latch 閂。

全局鎖就是指 RAC lock，就是不一樣主機之間的鎖，Oracle 採用了 DLM（Distributed Lock Management，分佈式鎖管理）機制。在 Oracle RAC 裏面，數據是全局共享的，就是說每一個進程看到的數據塊都是同樣的，在不一樣機器間，數據塊能夠傳遞。給出了 GRD目錄結構。

 

能夠看出 Mode、Role、n 構成了 RAC lock 的基本結構

1. Mode 有 N、S、X3 種方式
2. Role 有 Local 和 Global 兩種
3. N 有 PI 和 XI 兩種，通常 0 表示 XI，1 表示 PI
4. 全局內存管理
5. RAC 中的數據庫文件
6. RAC 中讀的一致性
7. 羣集就緒服務（CRS）
8. 全局資源目錄

一致性管理

數據一致性和併發性描述了 Oracle 如何維護多用戶數據庫環境中的數據一致性問題。在單用戶數據庫中，用戶修改數據庫中的數據，不用擔憂其餘用戶同時修改相同的數據。可是，在多用戶數據庫中，同時執行的多個事務中的語句能夠修改同一數據。同時執行的事務須要產生有意義的和一致性的結果。於是，在多用戶數據庫中，數據併發性和數據一致性的控制很是重要：數據併發性：每一個用戶能夠看到數據的一致性結果。ANSI/IOS SQL 標準（SQL 92）定義了 4 個事務隔離級別，對事務處理性能的影響也個不相同。這些隔離級別是考慮了事務併發執行必須避免的 3 個現象提出的。3 個應該避免的現象爲：  

1. 髒讀：一個事務能夠讀取其餘事務寫入但尚未提交的數據。  
2. 不可重複讀（模糊讀）：一個事務重複讀到之前讀到的和查詢到的數據，這些數據是其餘的已提交事務已經修改或者刪除的數據。
3. 幻影讀：一個事務重複運行查詢返回的一些列行，這些行包括其餘已經提交的事務已經插入的額外的行。

SQL92 根據這些對象定義了 4 個隔離級別，事務運行在特定的隔離級別容許特別的一些表現。以下表表示隔離級別阻止的讀現象。

 

OCR 結構

(一) OCR KEY 是樹形結構。

(二) OCR PROCESS 每一個節點都有 OCR CACHE 的複製，由 ORC MASTER 節點負責更新到 OCR DISK

Oracle Clusterware 後臺進程

自動啓動的腳本/etc/inittab 裏定義：

OCSSD（Clustery Synchronization Service）提供心跳機制監控集羣狀態

DISK HEARTBEAT

NETWORK HEARBEAT

CRSD（Clustery Ready Service）提供高可用、干預、關閉、重啓、轉移服務。

資源包括 nodeapps、database-related：前者每一個節點只須要一個便可正常工做，後一個與數據庫相關，不受節點限制，能夠爲多個。

EVMD： 這個進程負責發佈 CRS 產生的各類事件，仍是 CRS 和 CSS 兩個服務之間通訊的橋樑

RACGIMON： 這個進程負責檢查數據庫健康狀態，包括數據庫服務的啓動、中止和故障轉移。屬於持久鏈接，按期檢查 SGA。

OPROCD（Process Monitor Daemon）檢測 CPU hang（非 Linux 平臺使用）

RAC 的併發控制

DLM 分佈式鎖管理。

1. Non-Cache Fusion 資源：包括數據文件、控制文件、數據字典視圖 、Library Cache、Row Cache
2. Cache Fusion 資源：包括普通數據塊、索引數據塊、段頭、UNDO 數據塊。
3. GRD（Global Resource Directory）：記錄每一個數據塊在集羣間的分佈圖，在SGA中分master node與shadownode
4. PCM lock：mode role Past Image
5. LMS0（LOCK MANAGER SERVICE）：對應服務爲 GCS（Global Cache Service），主要負責數據塊在實例間傳遞Cache fusion 參數 GCS_SERVER_PROCESSES
6. LMD：對應服務爲 GES（Global ENQUEUE Service），主要負責傳遞過程當中鎖的管理。
7. LCK：負責 NON-CACHE FUSION 資源同步訪問，每一個實例有一個進程。
8. LMON：這個進程按期通訊每一個實例，對應服務爲 CGS（Cluster Group Service）。提供節點監控 node monitor，經過 GRD 中用位圖 0,1 來標誌。0：節點關閉 1：節點正常運行經過 CM 層按期通訊。
9. 兩種心跳機制：網絡心跳和控制文件磁盤心跳 3S 一次。
10. DIAG：監控狀態，寫日誌 alert.log
11. GSD：爲用戶提供管理接口。

---

RAC 的主要後臺進程

RAC 重構觸發條件

(一) NM（NODE MANAGEMENT）group

(二) 重構集羣觸發：有 node 加入或者離開集羣，由 NM 觸發 Network Heartbeat 異常：由於 LMON 或者 GCS、GES 通訊異常 ，由 IMR（Instance Membership Reconfiguration）controlfile heartbeat 觸發。

RAC 優缺點

RAC 優勢

(一) 多節點負載均衡

(二) 提供高可用性，故障容錯及無縫切換功能，將硬件和軟件的異常形成的影響最小化。

(三) 經過並行執行技術提供事務響應的時間 - 一般用於數據分析系統。

(四) 經過橫向擴展提升每秒交易數和鏈接數 - 一般用於 OLTP。

(五) 節約硬件成本，能夠使用多個廉價的 PC 服務器代替小型機大型機，節約相應的維護成本。

(六) 可擴展性好，能夠方便添加刪除節點，擴展硬件資源。

RAC 缺點

(一) 管理更復雜，要求更高

(二) 系統規劃設計較差時性能可能會不如單節點

(三) 可能會增長軟件成本(按照 CPU 收費)

 

共享存儲

在須要將一個 LUN （邏輯單元號）映射給多個節點、爲集羣提供一個共享的存儲卷時，同一個存儲 LUN 在各個主機端的 LUNID 必須是相同的。好比：

 (一) 在爲多個 ESX 節點建立一個 VMFS 卷的時候

(二) 在雙機 HA 集羣建立共享存儲的時候

時間一致性

集羣模式下，各個節點要協同工做，所以，各主機的時間必須一致。所以，各主機的時間必須一致。各個節點之間的時間差不能超時，通常若是超過 30s，節點極可能會重啓，因此要同步各節點的時間。例如，須要配置一個 ntp 時鐘服務器，來給 RAC 的各個節點進行時間同步。或者讓節點之間進行時間同步，保證各個節點的時間同步，可是沒法保證 RAC 數據庫的時間的準確性。

互聯網絡（或者私有網絡、心跳線）

集羣必須依賴內部的互聯網絡實現數據通信或者心跳功能。所以，採用普通的以太網仍是其餘的高速網絡(好比 IB)，就頗有講究，固然了，還有拿串口線實現心跳信息傳遞。此外，採用什麼樣的網絡參數對集羣總體的性能和健壯性都大有關係。

案例：

XX 市，4 節點 Oracle 10g RAC

操做系統採用的是 RHEL 4，按照默認的安裝文檔，設置網絡參數爲以下值：

net.core.rmem_default = 262144

net.core.rmem_max = 262144

執行一個查詢語句，須要 11 分鐘，修改參數：

net.core.rmem_default = 1048576

net.core.rmem_max = 1048576

再次執行僅需 16.2 秒。

固件、驅動、升級包的一致性

案例：

XX 市，HPC 集羣，運行 LS-DYNA(通用顯示非線性有限元分析程序)。

集羣存儲系統的環境說明：存儲系統的 3 個 I/O 節點經過 FC SAN 交換機鏈接到一個共享的存儲。

1. 1. 節點使用的 FC HBA 卡爲 Qlogic QLE2460;
   2. 光纖交換機爲 Brocade 200E
   3. 磁盤陣列爲 Dawning DS8313FF

故障現象

集羣到貨後發現盤陣與機器直連能通，兩個設備接 200E 交換機不通。後經測試交換機 IOS 版本問題致使不能正常認出盤陣的光纖端口，與交換機的供貨商聯繫更新了兩次 IOS，盤陣的端口能正常識別，但盤陣與機器相連仍是沒法找到盤陣。通過今天的測試發現三臺 I/O 節點採用的 HBA 卡 firmware 版本不一致。最先接光纖交換機及與盤陣直連的的 I/O1 的 firmware 爲 v4.03.02，今天又拿出來的兩臺 I/O 節點 firmware 爲 v4.06.03。用後兩臺測試後盤陣、機器、交換機之間能夠正常通訊，到今天晚上爲止沒有發現異常狀況。從目前的狀況判斷是QLE2460 firmware 爲 v4.03.01 的 HBA 卡與 200E IOS V5.3.1 有衝突者不兼容致使的故障。至於新的 HBA 卡 firmware爲 v4.06.03 與 200E IOS V5.3.1 鏈接的穩定性如何還要作進一步測試。

診斷處理結果

I/O 1 節點 HBA 卡的 fimware 升級到 v4.06.03 後鏈接 200E 找不到盤陣的故障已經獲得解決。實際上是一個 FCHBA 卡的固件版本不一致引發的問題。

共享文件 OCR 及 Voting Disk

Oracle Cluster Registry（OCR）：記錄 OCR 記錄節點成員的配置信息，如 database、ASM、instance、 listener、VIP 等 CRS 資源的配置信息,可存儲於裸設備或者羣集文件系統上。Voting disk : 即仲裁盤，保存節點的成員信息，當配置多個投票盤的時候個數必須爲奇數，每一個節點必須同時可以鏈接半數以上的投票盤纔可以存活。初次以外包含哪些節點成員、節點的添加和刪除信息。

安裝

在 Oracle RAC 中，軟件不建議安裝在共享文件系統上，包括 CRS_HOME 和 ORACLE_HOME，尤爲是 CRS 軟件，推薦安裝在本地文件系統中，這樣在進行軟件升級，以及安裝 patch 和 patchset 的時候能夠使用滾動升級(rolling upgrade)的方式，減小計劃當機時間。另外若是軟件安裝在共享文件系統也會增長單一故障點。若是使用 ASM 存儲，須要爲 asm 單獨安裝 ORACLE 軟件，獨立的 ORACLE_HOME，易於管理和維護，好比當遇到 asm 的 bug 須要安裝補丁時，就不會影響 RDBMS 文件和軟件。

腦裂症（split brain）

在一個共享存儲的集羣中，當集羣中 heartbeat 丟失時，若是各節點仍是同時對共享存儲去進行操做，那麼在這種狀況下所引起的狀況是災難的。ORACLE RAC 採用投票算法來解決這個問題，思想是這樣的：每一個節點都有一票，考慮有 A，B，C 三個節點的集羣情形，當 A 節點因爲各類緣由不能與 B，C 節點通訊時，那麼這集羣分紅了兩個 DOMAIN,A 節點成爲一個 DOMAIN，擁有一票；B,C 節點成爲一個 DOMAIN 擁有兩票，那麼這種狀況B，C 節點擁有對集羣的控制權，從而把 A 節點踢出集羣，對要是通 IO FENCING 來實現。若是是兩節點集羣，則引入了仲裁磁盤，當兩個節點不能通訊時，請求最早到達仲裁磁盤的節點擁用對集羣的控制權。網絡問題（interconnect 斷了），時間不一致；misscount 超時 等等，才發生 brain split，而此時爲保護整個集羣不受有問題的節點影響，而發生 brain split。oracle 採用的是 server fencing，就是重啓有問題的節點，試圖修復問題。固然有不少問題是不能自動修復的。好比時間不一致，而又沒有 ntp；網線壞了。。。這些都須要人工介入修復問題。而此時的表現就是有問題的節點反覆重啓。

集羣軟件

從 Oracle10g 起，Oracle 提供了本身的集羣軟件，叫作 Oracle Clusterware，簡稱 CRS，這個軟件是安裝 oraclerac 的前提，而上述第三方集羣則成了安裝的可選項 。同時提供了另一個新特性叫作 ASM，能夠用於 RAC 下的共享磁盤設備的管理，還實現了數據文件的條帶化和鏡像，以提升性能和安全性 (S.A.M.E: stripe and mirroreverything ) ，再也不依賴第三方存儲軟件來搭建 RAC 系統。尤爲是 Oracle11gR2 版本再也不支持裸設備，Oracle 將全力推廣 ASM，完全放棄第三方集羣組件支持。

Oracle Clusterware 的心跳

Oracle Clusterware 使用兩種心跳設備來驗證成員的狀態，保證集羣的完整性。

• l   一是對 voting disk 的心跳，ocssd 進程每秒向 votedisk 寫入一條心跳信息。
• l   二是節點間的私有以太網的心跳。

兩種心跳機制都有一個對應的超時時間，分別叫作 misscount 和 disktimeout：

• l   misscount 用於定義節點間心跳通訊的超時，單位爲秒;
• l   disktimeout ,默認 200 秒，定義 css 進程與 vote disk 鏈接的超時時間;

reboottime ，發生裂腦而且一個節點被踢出後，這個節點將在reboottime 的時間內重啓;默認是 3 秒。用下面的命令查看上述參數的實際值：

• l  # crsctl get css misscount
• l  # grep misscount $CRS_HOME/log/hostname/cssd/ocssd.log

在下面兩種狀況發生時，css 會踢出節點來保證數據的完整，：

(一) Private Network IO time > misscount，會發生 split brain 即裂腦現象，產生多個「子集羣」(subcluster) ，這些子集羣進行投票來選擇哪一個存活，踢出節點的原則按照下面的原則：節點數目不一致的，節點數多的 subcluster 存活;節點數相同的，node ID 小的節點存活。

(二) VoteDisk I/O Time > disktimeout ，踢出節點原則以下：失去半數以上 vote disk 鏈接的節點將在 reboottime 的時間內重啓。例若有 5 個 vote disk，當因爲網絡或者存儲緣由某個節點與其中>=3 個 vote disk 鏈接超時時，該節點就會重啓。當一個或者兩個 vote disk 損壞時則不會影響集羣的運行。

如何查看現有系統的配置

對於一個已經有的系統，能夠用下面幾種方法來確認數據庫實例的心跳配置，包括網卡名稱、IP 地址、使用的網絡協議。

 最簡單的方法，能夠在數據庫後臺報警日誌中獲得。使用 oradebug

SQL> oradebug setmypid

Statement processed.

SQL> oradebug ipc

Information written to trace file.

SQL> oradebug tracefile_name

/oracle/admin/ORCL/udump/orcl2_ora_24208.trc

找到對應 trace 文件的這一行：socket no 7 IP 10.0.0.55 UDP 16878

 從數據字典中獲得：

SQL> select * from v$cluster_interconnects;

                       

SQL> select * from x$ksxpia;

 

心跳調優和設置

爲了不心跳網絡成爲系統的單一故障點，簡單地咱們能夠使用操做系統綁定的網卡來做爲 Oracle 的心跳網絡，以 AIX 爲例，咱們能夠使用 etherchannel 技術，假設系統中有 ent0/1/2/3 四塊網卡，咱們綁定 2 和 3 做爲心跳：在 HPUX 和 Linux 對應的技術分別叫 APA 和 bonding

UDP 私有網絡的調優當使用 UDP 做爲數據庫實例間 cache fusion 的通訊協議時，在操做系統上須要調整相關參數，以提升 UDP傳輸效率，並在較大數據時避免出現超出 OS 限制的錯誤：

(一) UDP 數據包發送緩衝區：大小一般設置要大於(db_block_size * db_multiblock_read_count )+4k，

(二) UDP 數據包接收緩衝區：大小一般設置 10 倍發送緩衝區;

(三) UDP 緩衝區最大值：設置儘可能大(一般大於 2M)並必定要大於前兩個值;

各個平臺對應查看和修改命令以下：

Solaris 查看 ndd /dev/udp udp_xmit_hiwat udp_recv_hiwat udp_max_buf ;

修改 ndd -set /dev/udp udp_xmit_hiwat 262144

ndd -set /dev/udp udp_recv_hiwat 262144

ndd -set /dev/udp udp_max_buf 2621440

AIX 查看 no -a |egrep 「udp_|tcp_|sb_max」

修改 no -p -o udp_sendspace=262144

no -p -o udp_recvspace=1310720

no -p -o tcp_sendspace=262144

no -p -o tcp_recvspace=262144

no -p -o sb_max=2621440

Linux 查看 文件/etc/sysctl.conf

修改 sysctl -w net.core.rmem_max=2621440

sysctl -w net.core.wmem_max=2621440

sysctl -w net.core.rmem_default=262144

sysctl -w net.core.wmem_default=262144

HP-UX 不須要

HP TRU64 查看 /sbin/sysconfig -q udp

修改： 編輯文件/etc/sysconfigtab

inet: udp_recvspace = 65536

udp_sendspace = 65536

Windows 不須要

 

---

---

About Me

............................................................................................................................... ● 本文整理自網絡 ● 本文在itpub（http://blog.itpub.net/26736162）、博客園（http://www.cnblogs.com/lhrbest）和我的微信公衆號（xiaomaimiaolhr）上有同步更新 ● 本文itpub地址：http://blog.itpub.net/26736162/abstract/1/ ● 本文博客園地址：http://www.cnblogs.com/lhrbest ● 本文pdf版及小麥苗雲盤地址：http://blog.itpub.net/26736162/viewspace-1624453/ ● 數據庫筆試面試題庫及解答：http://blog.itpub.net/26736162/viewspace-2134706/ ● QQ羣：230161599     微信羣：私聊 ● 聯繫我請加QQ好友(646634621)，註明添加原因 ● 於 2017-06-02 09:00 ~ 2017-06-30 22:00 在魔都完成 ● 文章內容來源於小麥苗的學習筆記，部分整理自網絡，如有侵權或不當之處還請諒解 ● 版權全部，歡迎分享本文，轉載請保留出處 ............................................................................................................................... 拿起手機使用微信客戶端掃描下邊的左邊圖片來關注小麥苗的微信公衆號：xiaomaimiaolhr，掃描右邊的二維碼加入小麥苗的QQ羣，學習最實用的數據庫技術。