溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
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
h2:35:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1 </dev/null
h3:35:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1 </dev/null
h4: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 eth2/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
————— —————- ——— ——————————-
eth2 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
eth2 10.10.10.0 global cluster_interconnect
eth0 10.194.129.0 global public
刪除當前
td1-> oifcfg delif -global eth0
td1-> oifcfg delif -global eth2
重新添加
td1-> oifcfg setif -global eth0/10.194.128.0:public
td1-> oifcfg setif -global eth2/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
————— —————- ——— —————————-
eth2 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組日志即可。
六、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）集群。
隨著經濟的高速發展，企業規模的迅猛擴張，企業用戶的數量、數據量的爆炸式增長，對數據庫提出了嚴峻的考驗。對于所有的數據庫而言，除了記錄正確的處理結果之外，還面臨著以下幾方面的挑戰。
在數據庫上，組建集群也是同樣的道理，主要有以下幾個原因：
(一) 伴隨著企業的成長，業務量提高，數據庫的訪問量和數據量快速增長，其處理能力和計算速度也相應增大，使得單一的設備根本無法承擔。
(二) 在以上情況下，若扔掉現有設備，做大量的硬件升級，勢必造成現有資源的浪費，而且下一次業務量提升時，又將面臨再一次硬件升級的高額投入。于是，人們希望通過幾個中小型服務器組建集群，實現數據庫的負載均衡及持續擴展；在需要更高數據庫處理速度時，只要簡單的增加數據庫服務器就可以得到擴展。
(三) 數據庫作為信息系統的核心，起著非常重要的作用，單一設備根本無法保證系統的下持續運行，若發生系統故障，將嚴重影響系統的正常運行，甚至帶來巨大的經濟損失。于是，人們希望通過組建數據庫集群，實現數據庫的高可用，當某節點發生故障時，系統會自動檢測并轉移故障節點的應用，保證數據庫的持續工作。
(四) 企業的數據庫保存著企業的重要信息，一些核心數據甚至關系著企業的命脈，單一設備根本無法保證數據庫的安全性，一旦發生丟失，很難再找回來。于是，人們希望通過組建數據庫集群，實現數據集的冗余，通過備份數據來保證安全性。
數據庫集群技術是將多臺服務器聯合起來組成集群來實現綜合性能優于單個大型服務器的技術，這種技術不但能滿足應用的需要，而且大幅度的節約了投資成本。數據庫集群技術分屬兩類體系：基于數據庫引擎的集群技術和基于數據庫網關（中間件）的集群技術。在數據庫集群產品方面，其中主要包括基于數據庫引擎的集群技術的 Oracle RAC、Microsoft MSCS、IBM DB2UDB、Sybase ASE，以及基于數據庫網關（中間件）的集群技術的 ICX-UDS 等產品。
一般來講，數據庫集群軟件側重的方向和試圖解決的問題劃分為三大類：
只有 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 有以下兩個建議：
基于這個原因，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 各部分組成：
這樣的分層也是與 MySQL 本身把 SQL 處理和存儲分開的架構相關系的。MySQL cluster 的優點在于其是一個分布式的數據庫集群，處理節點和存儲節點都可以線性增加，整個集群沒有單點故障，可用性和擴展性都可以做到很高，更適合 OLTP 應用。但是它的問題在于：
雖然 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 理論：
定理：任何分布式系統只可同時滿足二點，沒法三者兼顧。
忠告：架構師不要將精力浪費在如何設計能滿足三者的完美分布式系統，而是應該進行取舍。
關系數據庫的 ACID 模型擁有 高一致性 + 可用性 很難進行分區：
(五) 跨數據庫事務
2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，也就是說傳統關系型數據庫要想實現一個分布式數據庫集群非常困難，關系型數據庫的擴展能力十分有限。而近年來不斷發展壯大的 NoSQL（非關系型的數據庫）運動，就是通過犧牲強一致性，采用 BASE 模型，用最終一致性的思想來設計分布式系統，從而使得系統可以達到很高的可用性和擴展性。那么，有沒有可能實現一套分布式數據庫集群，既保證可用性和一致性，又可以提供很好的擴展能力呢？
BASE 思想的主要實現有按功能劃分數據庫 sharding 碎片BASE 思想主要強調基本的可用性，如果你需要 High 可用性，也就是純粹的高性能，那么就要以一致性或容錯性為犧牲，BASE 思想的方案在性能上還是有潛力可挖的。
目前，已經有很多分布式數據庫的產品，但是絕大部分是面向 DSS 類型的應用，因為相比較 OLTP 應用，DSS 應用更容易做到分布式擴展，比如基于 PostgreSQL 發展的 Greenplum，就很好的解決了可用性和擴展性的問題，并且提供了很強大的并行計算能力。對于 OLTP 應用，業務特點決定其要求：高可用性，一致性， 響應時間短，支持事務和 join 等等。數據庫和 NoSQL當越來越多的 NoSQL 產品涌現出來，它們具備很多關系型數據庫所不具備的特性，在可用性和擴展性方面都可以做到很好。
第一，NoSQL 的應用場景非常局限，某個類型的 NoSQL 僅僅針對特定類型的應用場景而設計。而關系型數據庫則要通用的多，使用 NoSQL 必須搞清楚自己的應用場景是否適合。
第二，利用關系型數據庫配合應用架構， 比如 Sharding 和讀寫分離技術，同樣可以搭建出具備高可用和擴展性的分布式數據庫集群。
第三，關系型數據庫廠商依然很強大，全世界有大量的 用戶，需求必然會推動新的產品問世。
第四，硬件的發展日新月異，比如閃存的技術的不斷成熟，未來閃存可以作為磁盤與內存之間的 cache，或者完 全替代磁盤。而內存價格越來越低，容量越來越大，In-memory cache 或 database 的應用越來越廣泛，可以給應用帶來數量級的性能提升。數據庫面臨的 IO 問題將被極大改善。
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同步。
共享存儲文件系統（NFS），或甚至集群文件系統（如：OCFS2）主要被用于存儲區域網絡（所有節點直接訪問共享文件系統上存儲器），這就使得節點失效而不影響來自其他節點對文件系統的訪問，通常，共享磁盤文件系統用于高可用集群。
Oracle RAC的核心是共享磁盤子系統，集群中所有節點必須能夠訪問所有數據、重做日志文件、控制文件和參數文件，數據磁盤必須是全局可用的，允許所有節點訪問數據庫，每個節點有它自己的重做日志和控制文件，但是其他節點必須能夠訪問它們以便在那個節點出現系統故障時能夠恢復。
Oracle RAC 運行于集群之上，為 Oracle 數據庫提供了最高級別的可用性、可伸縮性和低成本計算能力。如果集群內的一個節點發生故障，Oracle 將可以繼續在其余的節點上運行。Oracle 的主要創新是一項稱為高速緩存合并的技術。高速緩存合并使得集群中的節點可以通過高速集群互聯高效地同步其內存高速緩存，從而最大限度地低降低磁盤 I/O。高速緩存最重要的優勢在于它能夠使集群中所有節點的磁盤共享對所有數據的訪問。數據無需在節點間進行分區。Oracle 是唯一提供具備這一能力的開放系統數據庫的廠商。其它聲稱可以運行在集群上的數據庫軟件需要對數據庫數據進行分區，顯得不切實際。企業網格是未來的數據中心，構建于由標準化商用組件構成的大型配置之上，其中包括：處理器、網絡和存儲器。Oracle RAC 的高速緩存合并技術提供了最高等級的可用性和可伸縮性。Oracle 數據庫 10g 和 OracleRAC 10g 顯著降低了運營成本，增強了靈活性，從而賦予了系統更卓越的適應性、前瞻性和靈活性。動態提供節點、存儲器、CPU 和內存可以在實現所需服務級別的同時，通過提高的利用率不斷降低成本。
Oracle RAC 10g 在 Oracle 數據庫 10g 運行的所有平臺上提供了一個完整集成的集群件管理解決方案。這一集群件功能包括集群連接、消息處理服務和鎖定、集群控制和恢復，以及一個工作負載管理框架（將在下文探討）。Oracle RAC 10g 的集成集群件管理具有以下優勢：
(一) 成本低。Oracle 免費提供這一功能。
(二) 單一廠商支持。消除了相互推諉的問題。
(三) 安裝、配置和持續維護更簡單。Oracle RAC 10g 集群件使用標準 Oracle 數據庫管理工具進行安裝、配置和維護。這一過程無須其它的集成步驟。
(四) 所有平臺，質量始終如一。與第三方產品相比，Oracle 對新軟件版本進行了更嚴格的測試。
(五) 所有平臺，功能始終如一。例如，一些第三方集群件產品限制了集群內可以支持的節點的數量。借助Oracle RAC 10g，所有平臺可以支持多達 64 個節點。用戶還可以在所有平臺上獲得一致的響應體驗，從而有效解決了高可用性挑戰，包括服務器節點故障、互連故障以及 I/O 隔離現象等。
(六) 支持高級功能。這包括集成監視和通知功能，從而在發生故障時，在數據庫和應用層之間實現快速協調的恢復。
RAC 是 Oracle 數據庫的一個群集解決方案，是有著兩個或者兩個以上的數據庫節點協調運作能力的。如下圖所示的 RAC 結構圖：
集群管理器（Cluster Manager）在集群系統中對其他各個模塊進行整合，通過高速的內連接來提供群集節點之間的通信。各節點之間內連接使用心跳線互聯，心跳線上的信息功能確定群集邏輯上的節點成員信息和節點更新情況，以及節點在某個時間點的運行狀態，保證群集系統正常運行。通信層管理節點之間的通信。它的職責是配置，互聯群集中節點信息，在群集管理器中使用由心跳機制產生的信息，由通信層負責傳輸，確保信息的正確到達。還有一些群集監視進程不斷驗證系統的不同領域運行狀況。例如，心跳監測不斷驗證的心跳機制的運作是否良好。在一個應用環境當中，所有的服務器使用和管理同一個數據庫，目的是分散每一臺服務器的工作量。硬件上至少需要兩臺以上的服務器，而且還需要一個共享存儲設備；同時還需要兩類軟件，一類是集群軟件，另外一類就是 Oracle 數據庫中的 RAC 組件。同時所有服務器上的 OS 都應該是同一類 OS，根據負載均衡的配置策略，當一個客戶端發送請求到某一臺服務的 listener 后，這臺服務器根據負載均衡策略，會把請求發送給本機的 RAC組件處理，也可能會發送給另外一臺服務器的 RAC 組件處理，處理完請求后，RAC 會通過群集軟件來訪問共享存儲設備。邏輯結構上看，每一個參加群集的節點有一個獨立的實例，這些實例訪問同一個數據庫。節點之間通過集群軟件的通信層（Communication Layer）來進行通信。同時為了減少 I/O 的消耗，存在一個全局緩存服務，因此每一個數據庫的實例，都保留了一份相同的數據庫 cache。RAC 中的特點如下：
在 Oracle9i 之前，RAC 稱為 OPS（Oracle Parallel Server）。RAC 與 OPS 之間的一個較大區別是，RAC 采用了Cache Fusion（高緩存合并）技術，節點已經取出的數據塊更新后沒有寫入磁盤前，可以被另外一個節點更新，然后以最后的版本寫入磁盤。在 OPS 中，節點間的數據請求需要先將數據寫入磁盤，然后發出請求的節點才可以讀取該數據。使用 Cache Fusion 時，RAC 的各個節點間數據緩沖區通過高速、低延遲的內部網絡進行數據塊的傳輸。下圖是一個典型的 RAC 對外服務的示意圖，一個 Oracle RAC Cluster 包含了如下的部分
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 需要有共享存儲，獨立于實例之外的信息，如上面提到的ocr 和 votedisk 以及數據文件都存放在這個共享存儲里的。有OCFS、OCFS2、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 共享存儲方式的對比如下：
為了讓 RAC 中的所有實例能夠訪問數據庫，所有的 datafiles、control files、PFILE/Spfile 和 redo log files 必須保存在共享磁盤上，并且要都能被所有節點同時訪問，就涉及到裸設備和集群文件系統等。RAC database 在結構上與單實例的不同之處：至少為每個實例多配置一個 redo 線程，比如：兩個實例組成的集群至少要 4 個 redo log group。每個實例兩個 redo group。另外要為每一個實例準備一個 UNDO 表空間。
1、redo 和 undo，每個實例在做數據庫的修改時誰用誰的 redo 和 undo 段，各自鎖定自己修改的數據，把不同實例的操作相對的獨立開就避免了數據不一致。后面就要考慮備份或者恢復時 redo log 和歸檔日志在這種情況下的特殊考慮了。
2、內存和進程各個節點的實例都有自己的內存結構和進程結構.各節點之間結構是基本相同的.通過 Cache Fusion（緩存融合）技術，RAC 在各個節點之間同步 SGA 中的緩存信息達到提高訪問速度的效果也保證了一致性。
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(異步鎖陷阱）來鎖定進程，這樣可以要求這些進程把當前的持有鎖置為較低級限制的模式。資源是內存結構，這些結構代表了數據庫中的組件，對這些組件的訪問必須為限制模式或者串行化模式。換一句話說，這個資源只能被一個進程或者一直實例并行訪問。如果這個資源當前是處于使用狀態，其他想訪問這個資源的進程必須在隊列中等待，直到資源變得可用。隊列是內存結構，它負責并行化對特殊資源的訪問。如果這些資源只被本地實例需求，那么這個隊列可以本地來獲得，而且不需要協同。但是如果這個資源被遠程實例所請求，那么本地隊列必須變成全球化。
在單機環境下，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 軟件結構可以分為四部分。
(一) Operation System-Dependent（OSD）
RAC 通過操作系統的相關軟件來訪問操作系統和一些與 Cluster 相關的服務進程。OSD 軟件可能由 Oracle 提供（windows 平臺）或由硬件廠商提供（unix 平臺）。OSD 包括三個自部分：
(二) Real Application Cluster Shard Disk Component
RAC 中這部分組件和單實例 Oracle 數據庫中的組件沒有什么區別。包括一個或者多個控制文件、一些列聯機重做日志文件、可選的歸檔日志文件、數據文件等。在 RAC 中使用服務器參數文件會簡化參數文件的管理，可以將全局參數和實例特定的參數存儲在同一個文件中。
(三) Real Application Cluster-Specific Daemon and Instance Processes包括以下部分：
(四) The Global Cache and Global Enqueue Service
全局緩存服務（GCS）和全局隊列服務（GES）是 RAC 的集成組件，用于協調對共享數據庫和數據庫內的共享資源的同時訪問。
GCS 和 GES 包括以下特性：
健忘問題是由于每個節點都有配置信息的拷貝，修改節點的配置信息不同步引起的。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 中的內容。
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. 當一個節點出現問題時會自動的轉到另一個節點上。
透明應用故障轉移（Transport Application Failover，TAF）是 oracle 數據提供的一項，普遍應用于 RAC 環境中，當然也可以用于 Data Guard 和傳統的 HA 實現的主從熱備的環境中。TAF 中的 Transparent 和 Failover，點出了這個高可用特性的兩大特點：
但是，TAF 是完美的嗎？是不是使用了 TAF，應用就能真的無縫地進行切換呢？對應用和數據庫有沒有其他什么要求？要回答這些問題，我們需要全面地了解、掌握 TAF。我始終認為，要用好一個東西，首先得掌握這個東西背后的工作原理與機制。首先來看看 Failover。Failover 有兩種，一種是連接時 Failover，另一種則是運行時 Failover。前者的作用在于，應用（客戶端）在連接數據庫時，如果由于網絡、實例故障等原因，連接不上時，能夠連接數據庫中的其他實例。后者的作用在于，對于一個已經在工作的會話（也就是連接已經建立），如果這個會話的實例異常中止等，應用（客戶端）能夠連接到數據庫的其他實例（或備用庫）。
負載均衡（Load-Banlance）是指連接的負載均衡。RAC 的負載均衡主要指的是新會話連接到 RAC 數據庫時，根據服務器節點的 CPU 負載判定這個新的連接要連接到哪個節點進行工作。Oracle RAC 可以提供動態的數據服務，負載均衡分為兩種，一種是基于客戶端連接的，一種是基于服務器端的。
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 特點：
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 幻境下，配置歸檔日志可以有多種選擇。
使用 NFS 的方式將日志直接歸檔到存儲，例如兩個節點，每個節點都有 2 個目錄，Arch2，Arch3 分別對應實例 1 和實例 2 產生的歸檔日志。每個實例都配置一個歸檔位置，歸檔到本地，然后通過 NFS 把對方的目錄掛到本地。
實例間歸檔（Cross Instance Archive）是上一種方式的變種，也是比較常見的一種配置方法。兩個節點都創建 2 個目錄 Arch2 和 Arch3 分別對應實例 1 和實例 2 產生的歸檔日志。每個實例都配置兩個歸檔位置。位置 1對應本地歸檔目錄，位置 2 對應另一個實例
使用 ASM 將日志歸檔到共享存儲，只是通過 Oracle 提供的 ASM，把上面的復雜性隱藏了，但是原理都一樣。
Trace 日志
Oracle Clusterware 的輔助診斷，只能從 log 和 trace 進行。 而且它的日志體系比較復雜。 alert.log：$ORA_CRS_HOME/log/hostname/alert.Log, 這是首選的查看文件。
Clusterware 后臺進程日志
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 也有相關的日志。
前面已經介紹了 RAC 的后臺進程，為了更深入的了解這些后臺進程的工作原理，先了解一下 RAC 中多節點對共享數據文件訪問的管理是如何進行的。要了解 RAC 工作原理的中心，需要知道 Cache Fusion 這個重要的概念，要發揮 Cache Fusion 的作用，要有一個前提條件，那就是互聯網絡的速度要比訪問磁盤的速度要快。否則，沒有引入 Cache Fusion 的意義。而事實上，現在 100MB 的互聯網都很常見。
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，全局隊列服務）進程管理使用集群節點之間的數據塊同步互聯。
這里還是有一些問題需要思考的：
鎖是在各實例的 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。它的好處是 可以由多個性能較差的機器構建出一個整體性能很好的集群，并且實現了負載均衡，那么當一個節點出現故障時，其上的服務會自動轉到另外的節點去執行，用戶甚 至感覺不到什么。
1、 操作系統：
failsafe 系統局限于 WINDOWS 平臺，必須配合 MSCS（microsoft cluster server），而 RAC 最早是在 UNIX 平臺推出的，目前已擴展至 LINUX 和 WINDOWS 平臺，通過 OSD（operating system dependent）與系統交互。對于高端的 RAC 應用，UNIX 依然是首選的平臺。
2、 系統結構：
FAILSAFE 采用的是 SHARE NOTHING 結構，即采用若干臺服務器組成集群，共同連接到一個共享磁盤系統，在同一時刻，只有一臺服務器能夠訪問共享磁盤，能夠對外提供服務。只要當此服務器失效時，才有另一臺接管共享磁盤。RAC 則是采用 SHARE EVERYTHING，組成集群的每一臺服務器都可以訪問共享磁盤，都能對外提供服務。也就是說 FAILSAFE 只能利用一臺服務器資源，RAC 可以并行利用多臺服務器資源。
3、 運行機理：
組成 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 結合使用時，甚至網絡也可配置成透明的。
4、 集群容量：
前者通常為兩臺，后者在一些平臺上能擴展至 8 臺。
5、 分區：
FAILSAFE 數據庫所在的磁盤必須是 NTFS 格式的，RAC 則相對靈活，通常要求是 RAW，然而若干 OS 已操作出了 CLUSTER 文件系統可以供 RAC 直接使用。綜上所述，FAILSAFE 比較適合一個可靠性要求很高，應用相對較小，對高性能要求相對不高的系統，而 RAC則更適合可靠性、擴展性、性能要求都相對較高的較大型的應用。
RAC 是 OPS 的后繼版本，繼承了 OPS 的概念，但是 RAC 是全新的，CACHE 機制和 OPS 完全不同。RAC 解決了 OPS 中 2 個節點同時寫同一個 BLOCK 引起的沖突問題。 從產品上來說 RAC 和 OPS 是完全不同的產品，但是我們可以認為是相同產品的不同版本
Data Guard 是 Oracle 的遠程復制技術，它有物理和邏輯之分，但是總的來說，它需要在異地有一套獨立的系統，這是兩套硬件配置可以不同的系統，但是這兩套系統的軟件結構保持一致，包括軟件的版本，目錄存儲結構，以及數據的同步（其實也不是實時同步的），這兩套系統之間只要網絡是通的就可以了，是一種異地容災的解決方案。而對于 RAC，則是本地的高可用集群，每個節點用來分擔不用或相同的應用，以解決運算效率低下，單節點故障這樣的問題，它是幾臺硬件相同或不相同的服務器，加一個 SAN（共享的存儲區域）來構成的。Oracle 高可用性產品比較見下表：
通常在 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 的基本結構
數據一致性和并發性描述了 Oracle 如何維護多用戶數據庫環境中的數據一致性問題。在單用戶數據庫中，用戶修改數據庫中的數據，不用擔心其他用戶同時修改相同的數據。但是，在多用戶數據庫中，同時執行的多個事務中的語句可以修改同一數據。同時執行的事務需要產生有意義的和一致性的結果。因而，在多用戶數據庫中，數據并發性和數據一致性的控制非常重要：數據并發性：每個用戶可以看到數據的一致性結果。ANSI/IOS SQL 標準（SQL 92）定義了 4 個事務隔離級別，對事務處理性能的影響也個不相同。這些隔離級別是考慮了事務并發執行必須避免的 3 個現象提出的。3 個應該避免的現象為： ? ?
SQL92 根據這些對象定義了 4 個隔離級別，事務運行在特定的隔離級別允許特別的一些表現。如下表表示隔離級別阻止的讀現象。
(一) OCR KEY 是樹形結構。
(二) OCR PROCESS 每個節點都有 OCR CACHE 的復制，由 ORC MASTER 節點負責更新到 OCR DISK
自動啟動的腳本/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 平臺使用）
DLM 分布式鎖管理。
(一) NM（NODE MANAGEMENT）group
(二) 重構集群觸發：有 node 加入或者離開集群，由 NM 觸發 Network Heartbeat 異常：因為 LMON 或者 GCS、GES 通信異常 ，由 IMR（Instance Membership Reconfiguration）controlfile heartbeat 觸發。
(一) 多節點負載均衡
(二) 提供高可用性，故障容錯及無縫切換功能，將硬件和軟件的異常造成的影響最小化。
(三) 通過并行執行技術提供事務響應的時間 - 通常用于數據分析系統。
(四) 通過橫向擴展提高每秒交易數和連接數 - 通常用于 OLTP。
(五) 節約硬件成本，可以使用多個廉價的 PC 服務器代替小型機大型機，節約相應的維護成本。
(六) 可擴展性好，可以方便添加刪除節點，擴展硬件資源。
(一) 管理更復雜，要求更高
(二) 系統規劃設計較差時性能可能會不如單節點
(三) 可能會增加軟件成本(按照 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 交換機連接到一個共享的存儲。
故障現象
集群到貨后發現盤陣與機器直連能通，兩個設備接 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 卡的固件版本不一致引起的問題。
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 文件和軟件。
在一個共享存儲的集群中，當集群中 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 使用兩種心跳設備來驗證成員的狀態，保證集群的完整性。
兩種心跳機制都有一個對應的超時時間，分別叫做 misscount 和 disktimeout：
reboottime ，發生裂腦并且一個節點被踢出后，這個節點將在reboottime 的時間內重啟;默認是 3 秒。用下面的命令查看上述參數的實際值：
在下面兩種情況發生時，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群，學習最實用的數據庫技術。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
