溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
1.CRS簡介
從Oracle 10G開始，oracle引進一套完整的集群管理解決方案—-Cluster-Ready Services，它包括集群連通性.消息和鎖.負載管理等框架.從而使得RAC可以脫離第三方集群件，當然，CRS與第三方集群件可以共同使用.
(1).CRS進程
CRS主要由三部分組成，三部分都作為守護進程出現(xiàn)
<1>CRSD：資源可用性維護的主要引擎.它用來執(zhí)行高可用性恢復(fù)及管理操作，諸如維護OCR及管理應(yīng)用資源，它保存著集群的信息狀態(tài)和OCR的配置，此進程以root權(quán)限運行.
<2>EVMD：事件管理守護進程.此進程還負責啟動racgevt進程以管理FAN服務(wù)器端調(diào)用，此進程以root權(quán)限運行
<3>OCSSD：集群同步服務(wù)進程.管理集群節(jié)點的成員資格，它以fatal方式啟動，因此進程發(fā)生故障將導(dǎo)致集群重啟，以防止數(shù)據(jù)壞死.同時，CSS還維護集群內(nèi)的基本鎖功能，以及負責監(jiān)控voting disk的腦裂故障。它以Oracle權(quán)限運行
此外，還有一個進程OPRCD，他是集群中的進程監(jiān)視程序，僅當平臺上的CRS不使用廠商群件時候才出現(xiàn)，且無論運行了多少實例，每個節(jié)點只會存在一組后臺進程.
來看一下這幾個守護進程:
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為數(shù)據(jù)庫所在主機的公共網(wǎng)絡(luò)IP，Private IP被用來私有高速互聯(lián)，而Oracle較前版本，增加了一個虛擬IP，用來節(jié)點發(fā)生故障時候更快的故障轉(zhuǎn)移，oracle利用每個節(jié)點的lisnter偵聽VIP，一旦發(fā)生故障，VIP將進行實際的故障切換，從而在其他的可用的節(jié)點上保持聯(lián)機，從而降低客戶應(yīng)用程序意識到節(jié)點故障所需要的時間。
VIP與Public IP必須在同一個網(wǎng)段內(nèi)。
(3).OCR，Voting disk
OCR(oracle集群注冊表)和Voting disk(表決磁盤)是CRS下的兩個重要組件，它們必須放在共享磁盤上，以保證每個節(jié)點都能對其訪問。
OCR包含了針對集群的一些配置信息，諸如:集群數(shù)據(jù)庫中的節(jié)點列表.CRS應(yīng)用程序.資源文件以及事件管理器的授權(quán)信息。他負責對集群內(nèi)的資源追蹤，從而獲知資源正在哪里運行，應(yīng)該可以在哪里運行。
Voting disk用來解決split-brain故障:如果節(jié)點丟失了與集群中其他節(jié)點的網(wǎng)絡(luò)連接，這些沖突由表決磁盤中的信息來解決
2.ASM相關(guān)
ASM (Automated Storage Management) 是Oracle 10G引入的一種文件類型，他提供了直接的I/O讀寫，是RAC體系下一套不錯的對數(shù)據(jù)文件存儲規(guī)劃的方案. ASM可以自動管理磁盤組，并提供數(shù)據(jù)冗余和優(yōu)化.后面章節(jié)會就ASM的管理以及ASM下的RAC管理，單獨講解.
3.RAC存儲/網(wǎng)絡(luò)需求
(1).存儲需求
共享存儲器是RAC的重要組件之一。它要求集群內(nèi)的節(jié)點可以同時讀寫物理磁盤。目前，支持共享存儲的文件類型也比較多，像Oracle自身提供的ASM，OCFS2以及三方提供的群集文件系統(tǒng)，都是可以選擇的類型。
表1.1.1顯示了RAC 體系架構(gòu)下各部分所支持的存儲類型 (暫不考慮三方集群文件系統(tǒng)，就ASM/raw device/OCFS2和普通文件系統(tǒng)來說)
表1.1.1 RAC各部分所支持的存儲類型
|
類別 |
支持的存儲類型 |
存儲位置 |
備注 |
|
Cluster 軟件 |
OCFS2，普通文件系統(tǒng) |
共享磁盤/本地磁盤 |
|
|
OCR，Voting disk |
OCFS2，raw device |
共享磁盤 |
|
|
數(shù)據(jù)庫軟件 |
OCFS2，普通文件系統(tǒng) |
共享磁盤/本地磁盤 |
|
|
數(shù)據(jù)庫文件 |
OCFS2，raw device，ASM |
共享磁盤 |
|
|
歸檔日志文件 |
OCFS2，ASM，普通文件系統(tǒng) |
共享磁盤/本地磁盤 |
|
|
備份/恢復(fù)文件 |
OCFS2，ASM，普通文件系統(tǒng) |
共享磁盤/本地磁盤 |
|
|
閃回日志文件 |
OCFS2，ASM |
共享磁盤 |
|
(2).網(wǎng)絡(luò)需求
每個節(jié)點主機上至少需要2張物理網(wǎng)卡，以便分配公有IP和私有IP地址。對于私有IP連接，每個集群節(jié)點通過專用高速網(wǎng)絡(luò)連接到所有其他節(jié)點，目的在于集群上的節(jié)點和實例交換信息狀態(tài)（鎖信息，全局緩存信息等）。通過高速互聯(lián)，Cache Fusion得以實現(xiàn)。
在實際環(huán)境中，高速互聯(lián)至少需要配置GB級的以太網(wǎng)，而且，最好不要使用交叉直連。
較好的解決方案是節(jié)點間配置專用交換機，這樣避免因為集群上一個節(jié)點宕掉而影響另外節(jié)點的正常工作。
4.其他
(1).后臺進程
圖1.4.1 Backgroud Process in RAC 10g
由于要維護多個實例同時訪問資源所必需的鎖定，因此，同single instance相比，RAC下增加了額外的一些進程。專門針對RAC的進程有如下幾種：
1. LMS(Global Cache Service) 全局緩存服務(wù)進程
LMS負責為緩存融合請求在實例間傳遞塊。當一致性請求的時候，LMS首先回滾塊，創(chuàng)建塊的讀一致性映像（CR），然后將該一致性版本通過高速互聯(lián)傳遞到處理此請求的遠程實例中的前臺進程上，LMS進程保證了在同一時刻只允許一個實例去更新數(shù)據(jù)塊。
LMS進程的數(shù)量由初始化參數(shù)GCS_SERVER_PROCESSES控制。Oracle最大支持36個LMS進程（0–9 and a–z），該初始化參數(shù)默認值為2。
2. LMD (Global Enqueue Service Daemon) 全局隊列服務(wù)守護進程
LMD負責管理全局隊列和全局資源訪問，并更新相應(yīng)隊列的狀態(tài)，此外還負責遠程節(jié)點資源的請求與死鎖的檢測。LMD與LMS進程互交工作，共同維護GRD。
3. LMON (Global Enqueue Service Monitor) 全局隊列服務(wù)監(jiān)控器進程
LMON是全局隊列服務(wù)的監(jiān)控器，他負責檢查集群內(nèi)實例的死亡情況并發(fā)起重新配置，當實例加入或者離開集群的時候，它負責重新配置鎖和資源。
4. LCK(Lock process) 鎖進程
LCK管理那些不是緩存融合的請求，例如library cahe, row cache.由于LMS進程提供了主要的鎖管理功能，因此每個節(jié)點實例上只有一個LCK進程。
DIAG (The Diagnostic Daemon）診斷守護進程
DIAG負責監(jiān)控實例的健康狀況并捕獲進程失敗的信息，并將失敗信息寫入用于失敗分析，該進程自動啟動且不需要人為調(diào)整，若失敗則自動重新啟動。
(2).緩存融合/緩存一致性
Cache Fusion是RAC工作原理的一個中心環(huán)節(jié).他的本質(zhì)就是通過互聯(lián)網(wǎng)絡(luò)在集群內(nèi)各節(jié)點的SGA之間進行塊傳遞，從而避免了首先將塊推送到磁盤，然后再重新讀入其他實例的緩存中，從而最大限度的減少I/O。當一個塊被讀入RAC環(huán)境中某個實例的緩存時，該塊會被賦予一個鎖資源（與行級鎖不同），以確保其他實例知道該塊正在被使用。之后，如果另一個實例請求該塊的一個拷貝，而該塊已經(jīng)處于前一個實例的緩存內(nèi)，那么該塊會通過互聯(lián)網(wǎng)絡(luò)直接被傳遞到另一個實例的SGA。如果內(nèi)存中的塊已經(jīng)被改變，但改變尚未提交，那么將會傳遞一個CR副本。這就意味著，只要可能，數(shù)據(jù)塊無需寫回磁盤即可在各實例緩存之間移動，從而避免了同步多實例的緩存所花費的額外I/O，由此，需要互聯(lián)網(wǎng)絡(luò)的速度是高速的，需要快于磁盤訪問的速度．
GCS負責維護全局緩沖區(qū)內(nèi)的緩存一致性，LMS進程是其主要組成部分。GCS確保同一時刻某個塊上，只能有來自一個實例上的進程能對其修改,同時，并獲得該塊的當前版本和前映像，以及塊所處的狀態(tài)（NULL,,Shared, Exclusive），模式(local/gobal)。
GES負責維護dictionary cache和library cache緩存一致性（這個與LCK是不同的）。由于存在某個節(jié)點上對數(shù)據(jù)字典的修改(比如ddl和dcl對object屬性的修改)，GES負責同步各節(jié)點上的字典緩存,消除差異。GES確保請求訪問相同對象的多個實例間不會出現(xiàn)死鎖。
GRD包含了所有共享資源的當前狀態(tài)信息，它由GES和GCS共同維護，GRD貯存在內(nèi)存中，被用來管理全局資源活動。比如：當一個實例第一次讀取某塊到SGA的時候，該塊的角色為LOCAL，GCS記錄此狀態(tài)到GRD，一旦有另外的實例請求該塊，GCS會更新GRD，將此塊的角色由LOCAL變?yōu)?/span>GLOBAL。
二 RAC安裝
不用把安裝RAC看成是多么困難的一件事情.足夠細心和耐性，充分的準備工作，然后加上一丁點運氣，相信你能很快部署好一個RAC測試環(huán)境.當然，虛擬環(huán)境和實際環(huán)境的安裝不盡相同，而且，生產(chǎn)系統(tǒng)環(huán)境的搭建需要經(jīng)過縝密的規(guī)劃和系統(tǒng)的測試.但大同小異，安裝過程不該稱為我們的絆腳石.
1.安裝規(guī)劃部署
安裝之前需重點規(guī)劃RAC系統(tǒng)各文件的存儲類型.可以參見表1.3.1。一個好的存儲規(guī)劃方案，可以省去很多后續(xù)的維護成本。
2. 安裝過程
安裝過程可以參考oracle聯(lián)機文檔install guid。(Vmware安裝可以參考Vincent Chan發(fā)表在oracle網(wǎng)站上的一文<使用 VMware Server 在 Oracle Enterprise Linux 上安裝 Oracle RAC 10g>.文中講的很詳細，在此簡單帶過.)。簡單列一下安裝RAC的幾個重要步驟
配置系統(tǒng)內(nèi)核參數(shù)以及環(huán)境
配置共享存儲
安裝CRS軟件
安裝RDBMS軟件
創(chuàng)建數(shù)據(jù)庫以及配置其他
3.幾點注意問題.
特別提一下vmware下的時間同步問題，在我的環(huán)境下，兩節(jié)點上時間差別很大.一開始采用vmware-toolbox工具同步宿主時間，效果不理想.可以在每個節(jié)點上放置一個小腳本，讓他每隔一段時間以另一個節(jié)點為基準同步時間.這樣，時間同步問題迎刃而解.在我的環(huán)境下，我設(shè)置每20秒同步一次時間.
rac1>cat date.sh
#!/bin/sh
while true
do
rdate -s rac2>dev/null 2>&1
sleep 10
done
三 RAC管理維護
同Single instance相比，RAC的管理維護要復(fù)雜一些。10g給我們提供了一個強大的EM管理工具，將很多管理維護工作簡單和界面化。我們也應(yīng)當習慣使用EM來高效的完成更多的工作。本文以下部分，將暫不討論EM方面的管理，著重于命令行方式。
1.CRS管理維護
(1).CRS相關(guān)的接口命令
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中各節(jié)點上resources的運行狀況,Resources的屬性等。
例如使用－t選項，檢查資源狀態(tài)：
[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參數(shù)，獲得資源權(quán)限。
[root@rac2 bin]# crs_stat -ls|grep vip
ora.rac1.vip root oinstall rwxr-xr—
ora.rac2.vip root oinstall rwxr-xr--
主要參數(shù)有-t/-v/-p/-ls/-f等。具體可以參見crs_stat –h
集群資源啟動/停止CRS_START/CRS_STOP
這組命令主要負責各個節(jié)點上resources的啟動/停止?？梢葬槍θ仲Y源(例如：crs_stop –all，表示停止所有節(jié)點上的resources),也可以針對節(jié)點上的某個特定的資源（例如：crs_start ora.rac2.ons,表示啟動節(jié)點rac2上的ONS）。
集群資源配置CRS_REGISTER/CRS_UNREGISTER/CRS_PROFILE/CRS_SETPERM
這組命令主要負責集群資源的添加刪除以及配置。
CRS_PROFILE:用來生成resource的profile文件(當然我們也可以手動編輯或者通過現(xiàn)有生成)，默認存放路徑$ORA_CRS_HOME/crs/profile目錄下，加參數(shù)-dir 手動指定目錄。默認名稱為resource_name.cap.
crs_profile -create resource_name -t application –a .. –r .. –o..
表3.1為 crs_profile中參數(shù)配置說明（比較多，挑一些說吧）：
|
參數(shù)名稱 |
說明 |
參數(shù)指令（以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 |
資源貯存的位置/節(jié)點 |
crs_profile –create resource_name –o –ap … |
|
AUTO_START |
資源自啟動 |
crs_profile –create resource_name –o –as … |
|
CHECK_INTERVAL |
資源監(jiān)控間隔 |
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 |
資源重啟嘗試次數(shù)(最大20次) |
crs_profile –create resource_name –o –ft … |
|
HOSTING_MEMBERS |
資源啟動或者failover的首要節(jié)點選擇 |
crs_profile –create resource_name –h … |
|
PLACEMENT |
資源啟動或者failover的節(jié)點選擇模式（balanced，balanced，balanced） |
crs_profile – create resource_name -p |
|
REQUIRED_RESOURCES |
當前資源所依賴的資源 |
crs_profile – create resource_name -r |
|
RESTART_ATTEMPTS |
資源重配置之前的嘗試啟動次數(shù) |
crs_profile –create resource_name –o –ra … |
|
SCRIPT_TIMEOUT |
等待ACTION_SCRIPT的結(jié)果返回時間 |
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 … 用來更新現(xiàn)有profile(更新的只是profile，而并不是對已經(jīng)注冊到crs里面的資源屬性的更改)
crs_register負責將resource的注冊到OCR。注冊的方法是先生成profile，然后運行
crs_register resource [-dir …]命令，同時，crs_register也具有update resource功能，具體辦法可以更新resource對應(yīng)的profile文件，然后運行crs_register -u resource_name [-dir …] 或者直接發(fā)布crs_register –update resource_name …
比如，我將rac節(jié)點上的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參數(shù)。
crs_setperm用來設(shè)置resource的權(quán)限（諸如設(shè)置owner，用戶的讀寫權(quán)限等），更改owner用-o參數(shù)，更改group用-g，更改用戶權(quán)限用-u，在此不多舉例了。
<2>.CRSCTL
用crsctl check crs，檢查crs的健康情況。
[root@rac1 ~]# crsctl check crs
CSS appears healthy
CRS appears healthy
EVM appears healthy
用crsctl控制CRS服務(wù)
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的管理配置工具。相關(guān)用法參照srvctl -h
（1） srvctl add/delete .. 添加刪除資源。譬如我們在進行數(shù)據(jù)庫單實例遷移到rac的時候，可以用這個工具手工注冊database或者asm實例到OCR。
（2） srvctl status … 資源的狀態(tài)監(jiān)測
（3） srvctl start/stop … 資源的啟動/停止，這個可以和crs_start/crs_stop互交使用。
（4） srvctl modify .. 重新定義資源的屬性
………………………………………………………..
(2).OCR的管理維護
<1> OCR的狀態(tài)驗證：
可以使用ocrcheck工具來驗證OCR的狀態(tài)以及空間使用情況。在Lunix下，/etc/oracle/ocr.loc文件記錄了OCR使用的設(shè)備情況。
[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的節(jié)點上執(zhí)行命令即可。
[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，鏡像會自動轉(zhuǎn)變成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
可以看到現(xiàn)在的ocrconfig_loc自動變?yōu)橄惹暗膐crmirrorconfig_loc設(shè)備。
<3> 邏輯備份/恢復(fù)
備份命令：
ocrconfig –export [ path ]
還原命令
ocrconfig –import [ path ]
還原OCR的時候，需要停掉各節(jié)點crs服務(wù)。還原完成后，重新啟動CRS。(如果有必要，注意在每個節(jié)點分別修改ocr.loc的對應(yīng)使用設(shè)備)
<4> 物理備份/恢復(fù)
CRSD負責每4個小時進行一次OCR的備份，默認備份路徑在$ORA_CRS_HOME/cdate/crs下，
可以使用ocrConfig –showbackup查看備份情況，如果想更改物理備份路徑，可以使用ocrconfig –backuploc [ path ] 來完成
物理恢復(fù)命令：
ocrconfig –restore [ path ]
同樣,還原OCR的時候，需要停掉各節(jié)點crs服務(wù)。還原完成后，重新啟動CRS。(如果有必要，注意在每個節(jié)點分別修改ocr.loc的對應(yīng)使用設(shè)備)
<5> ocrdump
ocrdump可以將ocr信息導(dǎo)出成ascii文本，用于給Oracle Supoort提供檢修。
命令如下：
ocrdump
(3).Voting disk管理維護
Voting disk的維護相對簡單些。
<1> Votingdisk 狀態(tài)查詢
[root@rac1]# crsctl query css votedisk
0 /dev/raw/raw2
located 1 votedisk(s).
<2>在線添加、刪除votingdisk
Oracle建議配置奇數(shù)個votingdisk，添加/刪除可以在線完成，在某個online的節(jié)點上執(zhí)行命令即可。
添加votingdisk命令：
crsctl add css votedisk [path] -force
刪除votingdisk命令：
crsctl add css votedisk [path] -force
<3>votingdisk備份恢復(fù)
備份、恢復(fù)采用dd命令?；謴?fù)的時候，注意停掉各節(jié)點上的CRS服務(wù)。
2.RDBMS管理維護
(1).spfile以及相關(guān)參數(shù)說明
最普遍情況，節(jié)點共用同一個spfile文件，放置在共享存儲上，而每個節(jié)點上，相應(yīng)目錄下有一個pfile文件，而這個pfile文件指向共享存儲上的spfile。
當我們需要修改某一節(jié)點上的paremeter的時候，需要顯示的指定sid，例如：
SQL>alter system set sga_target=1024M scope=spfile sid=’rac1’;
System Altered.
這樣，節(jié)點rac1上的sga_target參數(shù)被修改，不會影響其余節(jié)點上的參數(shù)設(shè)置。如果不加sid，默認為sid＝’*’，也就是對所有節(jié)點生效。
RAC下，有一些不同與單實例的參數(shù)，列舉如下：
① cluster_database
一般情況下，該參數(shù)在rac各實例下應(yīng)該設(shè)置為true。在一些特別情況下，比如upgrade等，需要將該參數(shù)設(shè)置成false。
② db_name/db_unique_name/instance_name
各節(jié)點db_name需要一致，db_unique_name也需要一致(這與standby是不同的)。而instance_name配置成各個節(jié)點的實例名稱。
③ instance_number
該參數(shù)表示節(jié)點上實例的實例號。
④ thread
該參數(shù)用來標示實例使用的redo線程。線程號與節(jié)點號/實例號沒有直接關(guān)聯(lián)。
⑤ local_listener
該參數(shù)用來手工注冊監(jiān)聽。為解決ORA-12514錯誤，可以設(shè)置該參數(shù)。
⑥ remote_listener
該參數(shù)用來進行服務(wù)器端負載均衡配置。
⑦ cluster_interconnects
該參數(shù)用來指定集群中IPC通信的網(wǎng)絡(luò)。如果集群中有多種網(wǎng)絡(luò)用于高速互聯(lián)，需要配置該參數(shù)。對于多個IP地址，用冒號將其隔開。對于集群中當前使用的互聯(lián)地址，可以查詢視圖gv$cluster_interconnects或著oradebug ipc來查看。
⑧ max_commit_propagation_delay
該參數(shù)用于配置SCN的產(chǎn)生機制。在rac下,SCN的同步有2種模式:(1) Lamport Scheme.該模式下，由GES管理SCN的傳播同步，max_commit_propagation_delay表示SCN同步所允許的最大時間。在該模式下，全局SCN并非完全同步，這在高并發(fā)的OLTP系統(tǒng)中，可能會對應(yīng)用造成一定的影響。(2) Broadcast on Commit scheme. 該模式下，一旦任何一個實例上事務(wù)發(fā)布commit，都立即同步SCN到全局。
在10g R1下，該參數(shù)默認數(shù)值為700，即采用Lamport Scheme模式。而在10g R2下，該參數(shù)默認數(shù)值為0，采用Broadcast on Commit scheme模式 (設(shè)置小于700的某一值，都將采用該模式) 。采用何種方式，可以從alert.log中獲知。該參數(shù)值需要每個節(jié)點保持一致。
(2). Redo/Undo管理
?RAC下的Redo管理
同單實例的系統(tǒng)一樣，每個節(jié)點實例都需要至少2組logfile。各節(jié)點實例有自己獨立的重做日志線程(由初始化參數(shù)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
重做日志需要部署到共享存儲中，必須保證可被所有的集群內(nèi)的節(jié)點實例訪問。當某個節(jié)點實例進行實例/介質(zhì)恢復(fù)的時候，該節(jié)點上的實例將可以應(yīng)用集群下所有節(jié)點實例上的重做日志文件(如果需要)，從而保證恢復(fù)可以在任意可用節(jié)點進行。
?RAC下alter system switch logfile 與alter system archive log current 區(qū)別
alter system switch logfile僅對當前發(fā)布節(jié)點上的對應(yīng)redo thread進行日志切換并歸檔。
alter system archive log current對集群內(nèi)所有節(jié)點實例上的redo thread進行切換并歸檔（在節(jié)點實例可用情況下，分別歸檔到各節(jié)點主機的歸檔目的地，當節(jié)點不可用時候，該線程日志歸檔到命令發(fā)布節(jié)點的歸檔目的地）
?RAC下的Undo管理
RAC下的每個節(jié)點實例，也需要有自己單獨的撤銷表空間。由初始化參數(shù) *.Undo_tablespace 指定。同REDO一樣，UNDO表空間也需要部署到共享存儲，雖然每個節(jié)點上UNDO的使用是獨立的，但需要保證集群內(nèi)其他節(jié)點實例對其訪問，以完成構(gòu)造讀一致性等要求。
SQL>alter system set undo_tablespace=undo1 sid=’demo1’;
SQL>alter system set undo_tablespace=undo2 sid=’demo2’;
(3).Archivelog/flashback配置管理
在RAC下，Archivelog可以放置到本地磁盤，也可以放置到共享存儲。需要對Archivelog的放置有合理的部署，如果放置到本地磁盤，會增加備份恢復(fù)的復(fù)雜程度。
閃回區(qū)必須部署到共享存儲上，開啟前，需要配置db_recovery_file_dest、db_recovery_file_dest_size、db_flashback_retention_target等參數(shù)。
下面在一個非歸檔非閃回的database上，開始歸檔與閃回。
?更改相關(guān)參數(shù)
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
?停掉所有節(jié)點實例.開啟過程在一個實例上完成。
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那樣，設(shè)置初始化參數(shù)cluster_database＝false.這無疑簡化了操作。
(4).ASM下的RAC管理
?ASM下的參數(shù)文件
RAC下，每個節(jié)點上有運行有一個ASM實例，而rdbms instance就運行在這個asm實例上。Asm實例是本地的。同rdbms實例一樣，他需要有參數(shù)文件，參數(shù)文件在每個節(jié)點的相應(yīng)目錄下。
下面是我的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實例中比較重要的參數(shù):
instance_type：用來說明實例是ASM 還是RDBMS 類型
asm_diskgroups：ASM磁盤組，asm實例啟動的時候會自動mount
asm_diskstring：該參數(shù)用來說明能夠創(chuàng)建diskgroup的磁盤設(shè)備,默認值是NULL
asm_power_limit:該參數(shù)用來設(shè)置進程 ARBx 的數(shù)量，負責控制負載平衡操作的速度。取值 從 0 到 11。默認值為1。
?用于記錄ASM實例信息的數(shù)據(jù)字典。
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下在線添加、刪除磁盤組
在一個節(jié)點上添加diskgroup，集群上另外的節(jié)點并不會自動mount新添加的diskgroup，需要手動執(zhí)行。
節(jié)點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
此時觀察節(jié)點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時，保留一個節(jié)點diskgroup為mount狀態(tài)，將其余節(jié)點上的diskgroup dismount，然后執(zhí)行刪除命令。
<2>.在線添加、刪除磁盤
RAC下在線添加磁盤與刪除磁盤與單實例并不差別。需要注意該操作會引起磁盤組的重新平衡，并確保刪除磁盤的時候該磁盤組有足夠的剩余空間。
節(jié)點1：
SQL> alter diskgroup dg6 add disk '/dev/raw/raw7' name dg6_disk7;
Diskgroup altered.
節(jié)點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
刪除磁盤在某一節(jié)點操作即可，不做舉例驗證。
關(guān)于ASM的更多管理命令，就不多列舉了。
3.Database備份/恢復(fù)
RAC下的備份恢復(fù)跟單實例的備份恢復(fù)實質(zhì)上沒有太大的差別，需要注意的是備份/恢復(fù)的時候當前節(jié)點對所有數(shù)據(jù)文件/歸檔日志的可見。在一個數(shù)據(jù)文件和歸檔日志全部放在共享存儲上的RAC系統(tǒng)，備份與恢復(fù)過程與單實例下的幾乎一樣。而歸檔日志如果采用的是本地磁盤，就需要另加注意。下面分別來模擬這個備份恢復(fù)過程。
(1).Archivelog對各節(jié)點可見的備份/恢復(fù)
在這種模式下，備份恢復(fù)可以在任意一個可用節(jié)點執(zhí)行即可，跟單實例并不太大區(qū)別。
?對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
?添加數(shù)據(jù)，用于測試恢復(fù)效果
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
?模擬故障/恢復(fù)
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
?恢復(fù)完畢，來看一下驗證數(shù)據(jù)：
SQL> select count(*) from kevinyuan.test_b;
COUNT(*)
12
(2). Archivelog對各節(jié)點不可見的備份/恢復(fù)
如果arhivelog采用本地磁盤,歸檔日志并不是對任意節(jié)點可見。備份archivelog的時候，如果采用和上述類似的備份方案，必然會導(dǎo)致一些歸檔日志由于無法access而拋出異常?？梢圆扇∪缦碌膫浞莘绞剑康木褪鞘沟脗浞萃ǖ滥軌騛ccess所有的數(shù)據(jù)字典中記錄的歸檔日志信息。
恢復(fù)的時候,copy所有節(jié)點產(chǎn)生的相關(guān)備份片/集和歸檔日志文件到待恢復(fù)節(jié)點，在一個節(jié)點上執(zhí)行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)備份數(shù)據(jù)庫
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節(jié)點2上的備份文件/歸檔日志文件到節(jié)點1相應(yīng)目錄下。
rac2-> scp /backup/database/* rac1:/backup/database/
rac2-> scp /archive/demo2/* rac1:/archive/demo1
(3)恢復(fù)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
至此，恢復(fù)完成。
生產(chǎn)庫的備份需要縝密部署與模擬測試，不同的數(shù)據(jù)庫類型也需要制定不同的方案實現(xiàn)。對DATABASE來說，備份重于泰山，不能抱有任何僥幸心理。
Service.Failover and Load Balance
1.Service
服務(wù)是rac體系中相當重要的概念，它為應(yīng)用提供高可用和多樣化的解決方案。實際中，我們可以創(chuàng)建不同性質(zhì)的service來滿足我們應(yīng)用的不同需求。
10gR2下，可以通過以下幾個方式創(chuàng)建服務(wù)。
(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命令創(chuàng)建
10g提供了dbms_service用于管理服務(wù)并進行功能擴展.
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).其他等..
不管采用哪種方式，實質(zhì)都是通過修改service_names而向lisnter動態(tài)注冊服務(wù).
2. failover and load banance
RAC為應(yīng)用提供了高性能和高可用的服務(wù)，對用戶來講，核心的功能便是failover與load banance.
(1)Failover
在10gR2版本里，F(xiàn)ailover的實現(xiàn)方式有兩種，一種是TAF(Transparent Application Failover), 一種是FCF(Fast Connection Failover).
TAF以及實現(xiàn):
TAF是net層透明故障轉(zhuǎn)移,是一種被動的故障轉(zhuǎn)移方式, 依賴于VIP.可以通過客戶端和服務(wù)器端配置taf的策略.
<1> client端taf配置
以下是一個簡單的具有taf功能的tnsnames.ora 內(nèi)容
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策略的參數(shù)說明：
|
參數(shù) |
描述 |
|
FAILOVER |
Failover控制開關(guān)（on/off），如果為off，不提供故障切換功能，但連接時會對address列表進行依次嘗試，直到找到可用為止 |
|
TYPE |
兩種類型：session /select Session: 提供session級別的故障切換。 Select：提供select級別的故障切換，切換過程對查詢語句透明，但事物類處理需要回滾操作 |
|
METHOD |
兩種類型:basic/preconnect Basic:client同時只連接一個節(jié)點，故障切換時跳轉(zhuǎn)到另外節(jié)點 Preconnect：需要與backup同時使用，client同時連接到主節(jié)點和backup節(jié)點 |
|
BACKUP |
采用Preconnect模式的備用連接配置 |
|
RETRIES |
故障切換時重試次數(shù) |
|
DELAY |
故障切換時重試間隔時間 |
<2> Server端TAF配置
10gR2提供Server端的TAF配置，需要調(diào)用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及實現(xiàn)
FCF是10g引進的一種新的failover機制，它依靠各節(jié)點的ons進程，通過廣播FAN事件來獲得各節(jié)點的運行情況，是一種前攝性的判斷，支持JDBC/OCI/ODP.NET
(1).ons配置
onsctl工具配置各節(jié)點的local /remote節(jié)點以及端口.配置文件路徑:$ORACLE_HOME/opmn/ons.config.
使用 onsctl debug 跟蹤ons進程是否正常運行。
(2).配置連接池（以jdbc為例）
需要連接池支持Implicit Connection Cache，設(shè)置FastConnectionFailoverEnabled=true.
將ojdbc14.jar / ons.jar等加入CLASSPATH.具體代碼可以參見聯(lián)機文檔或metalink相關(guān)文檔.
(2) Load Balance
10g的 load balance同前版本相比有了很大功能上的改進，依據(jù)Load Balancing Advisory，提供了Runtime Connection Load Balancing的策略，但個人認為這也是個相對矛盾所在。越是細化的負載均衡機制，越是有加重cache fusion的可能，這對rac的整體性能是個考驗。
load balance主要有兩種實現(xiàn)方式:一種是Connection Load Balancing(CLB)，另外一種是Runtime Connection Load Balancing(RCLB)。
CLB分為客戶端client-side和服務(wù)器端server-side兩種。
client-side需要在tnsname.ora添加LOAD_BALANCE=ON來實現(xiàn)，提供基于平衡連接數(shù)的負載方案.
server-side需要修改remote_listener參數(shù),讓listener能監(jiān)聽到集群中的所有節(jié)點,通過PMON來收集節(jié)點上的負載信息。
FCF默認支持RCLB功能，RCLB通過load balancing advisory事件來對連接提供更好的服務(wù)。RCLB有兩種負載平衡方案可供選擇—-基于總體service name和基于總體Throughput。可以通過dbms_service來設(shè)置具體的goal方案。
SQL> exec dbms_service.modify_service(service_name => ‘TEST’, goal => DBMS_SERVICE.GOAL_SERVICE_TIME);
至于這兩種方式的具體差異，在我的測試中，并沒有得到明顯的體現(xiàn)。
Load Balanc這部分是我存疑最多的地方，查閱了很多文檔，說法不一，且沒有翔實的案例證明，在此也希望有過研究的朋友們做指正。
RAC下其他維護實施相關(guān)/案例
本環(huán)節(jié)側(cè)重一些RAC工程維護相關(guān)的實際案例,暫舉例以下案例
1.集群中主機名的更改
2.集群中IP地址的更改
3.集群中節(jié)點的添加/刪除
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并編輯相關(guān)文件，重啟主機（步驟略）
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′
在每個節(jié)點依次執(zhí)行：
[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 版本，在最后一個節(jié)點上執(zhí)行的時候會因為vip的bug拋出異常，在該節(jié)點上調(diào)用VIPCA圖形化界面。
這樣gsd、ons和vip已經(jīng)全部注冊到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配置共有/私連網(wǎng)絡(luò)
td1-> oifcfg setif -global eth0/10.194.129.0:public
td1-> oifcfg setif -global eth2/10.10.10.0:cluster_interconnect
7.注冊其他資源到集群
(1)注冊監(jiān)聽到集群
修改監(jiān)聽配置文件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圖形化界面來配置監(jiān)聽.
(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
登陸數(shù)據(jù)庫檢查db使用的內(nèi)連接鏈路
SQL> select * from v$cluster_interconnects;
NAME IP_ADDRESS IS_PUBLIC SOURCE
————— —————- ——— ——————————-
eth2 10.10.10.145 NO Oracle Cluster Repository
如果使用了OCFS作為共享文件格式，注意在啟動數(shù)據(jù)庫前檢查相應(yīng)OCFS的配置并確認ocfs是否能正常掛載使用。
2.集群中IP地址的更改
IP地址的更改比hostname的更改相對容易一些。對于同網(wǎng)段的public/private IP更改，無需進行特別操作。如果是不同網(wǎng)段，需要使用oifcfg處理。因為VIP是作為資源注冊到OCR，所以任何VIP的改動都需調(diào)用相關(guān)命令進行處理。
以上處理都需要在集群資源停掉的基礎(chǔ)上操作。
以下是修改前后的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.停掉各資源
數(shù)據(jù)庫正常關(guān)庫，其余資源使用crs_stop 停止。
2.重新修改網(wǎng)卡ip/gateway/host文件等,重啟網(wǎng)絡(luò)等相關(guān)服務(wù)
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.修改監(jiān)聽listener配置文件
7.啟動集群各節(jié)點資源并驗證
td1-> crs_start –all
登陸數(shù)據(jù)庫，檢驗內(nèi)連接是否生效。
SQL> select * from v$cluster_interconnects;
NAME IP_ADDRESS IS_PUBLIC SOURCE
————— —————- ——— —————————-
eth2 10.10.1.145 NO Oracle Cluster Repository
<三>.集群中節(jié)點的刪除/添加
同9i的節(jié)點刪除/添加相比，10g對節(jié)點的添加和刪除相對來說略顯麻煩，但操作起來更加規(guī)范。
因為集群件的存在，需調(diào)用一系列接口命令將資源從OCR中添加/刪除，本文不再對該案例做詳細描述，具體參見oracle官方聯(lián)機文檔RAC部分–Adding and Deleting Nodes and Instances on UNIX-Based Systems.
<四>.升級與遷移
RAC的遷移與升級并不比單實例復(fù)雜多少。對于一個rac新手來說，在思想上也無需覺得這是個很龐雜的事情，當然前提是你有足夠的單實例方面的基礎(chǔ)知識并對此深刻理解。
比如，利用rman備份，我們可以方便的將一個運行在單節(jié)點的實例遷移到rac環(huán)境下。需要做的重點，僅僅是遷移數(shù)據(jù)庫(你可以想象成是單實例對單實例)，然后編輯參數(shù)文件，添加其他節(jié)點啟動db所必要的redo和undo，并注冊數(shù)據(jù)庫資源到集群中以便管理。
如果你的遷移或升級有停機時間的限制，那大部分情況下重點的問題并不在于被操作對象是RAC架構(gòu)，而在于如何制定你的MAA策略。比如你需要運用一些表空間傳輸或者高級復(fù)制/流等方面的特性來壓縮停機時間，這也許因為是RAC架構(gòu)而增加了整個施工的難度，但很多時候問題的重點并不在于此。
接下來提供一個9I RAC同機靜默升級到 10G RAC的案例,詳細可參見我的一篇blog http://www.easyora.net/blog/9i_rac_upgrade_10g_rac.html
<五>.高可用架構(gòu):RAC+DG
應(yīng)該說，rac+dg企業(yè)級的架構(gòu)在高可用和災(zāi)備方面來說還是有相當大的市場。
在搭建與管理方面，rac(主)+DG(備)的過程與單實例的主備也無太大異同。需要注意以下方面(但不限于以下方面):
1.log gap的檢測問題
注意正確配置fal_server與fal_clicent參數(shù)，尤其是對于rac主庫歸檔到各自節(jié)點上的情況下,standby端gap server需要將每個主庫節(jié)點都涵蓋進去。
2.switchover/failover注意事項
做任何切換的時候，需要將rac端只保留一個alive的實例，其余實例關(guān)閉后，切換步驟跟單節(jié)點dg基本一致。
3.standby logfile問題
如果采用LGWR傳輸日志，需要備庫端添加standby logfile日志。需要注意添加的standby logfile的thread要與主庫一致。如果你的主庫節(jié)點有3個實例，那需要添加3大組與rac主庫相同thread號的備用日志，每個thread至少2組日志即可。
六、RAC監(jiān)控優(yōu)化
1.思路及等待事件說明
鑒于RAC體系的復(fù)雜性，RAC的優(yōu)化比單實例的優(yōu)化給我們提出了更高的難度和要求。大部分情況下，單實例上的優(yōu)化方法在RAC結(jié)構(gòu)下同樣適用。
RAC優(yōu)化的2個核心問題:
(1).減少shared pool的壓力:減少對數(shù)據(jù)字典的爭用，減少硬解析。
因為row cache/library cache是全局的，頻繁的數(shù)據(jù)字典爭用/硬解析在RAC環(huán)境下會造成比單實例更嚴重的性能后果。
(2).減少因Cache fusion帶來的全局塊傳輸和爭用
頻繁的Cache fusion會帶來一系列數(shù)據(jù)塊上的全局爭用。如何減少邏輯讀，減少數(shù)據(jù)在實例之間共享傳輸，是RAC體系對應(yīng)用設(shè)計和部署的新要求
Cache fusion性能是影響RAC系統(tǒng)性能的一個極為重要的方面。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
該等待事件表示資源從遠程實例讀取到本地實例所花費的時間。出現(xiàn)該事件并不能說明什么問題，如果等待時間過長，可能表示內(nèi)聯(lián)網(wǎng)絡(luò)存在問題或者有嚴重的塊爭用。
gc buffer busy
buffer busy waits在全局上的延伸。出現(xiàn)該等待時間一般可能是塊的爭用問題。
Enquenue類
RAC中，常見的Enquenue有enq: HW – contention/ enq: TX - index contention/enq等，在跨節(jié)點高并發(fā)的insert環(huán)境中很容易出現(xiàn)。
諸如gc current-2way/3way.gc current/cr grant等事件，這些事件只是提供了塊傳輸和消息傳輸方面的細節(jié)或是結(jié)果，一般情況下無需太投入關(guān)注。
2.性能診斷
性能上的調(diào)整很難給出一個定式，但指導(dǎo)思想上可以實現(xiàn)很大方面的統(tǒng)一。
AWR/ASH等報告可以作為RAC系統(tǒng)中一個強有力的性能采集和診斷工具。同單實例的報告相比，AWR中的RAC Statistics部分給我們提供了詳細的GES、GCS性能采樣，結(jié)合全局等待事件，定位集群問題上的癥狀。
在RAC結(jié)構(gòu)下，Segment Statistics部分是我們更加需要注意的地方。如果你還是習慣使用STATSPACK來進行性能采集，建議至少將收集級別設(shè)置為7。該部分為我們提供了詳細的Segment級別的活動情況，有助于我們定位全局的HOT table /HOT index，分析全局資源排隊爭用的根源。
要重視DBA_HIS開頭的一系列視圖的作用，這將幫我們將問題定位的更加細化，甚至定位到SQL級別。糟糕的SQL效率拖垮系統(tǒng)性能的案例比比皆是，這在RAC中往往更加常見。dba_hist_active_sess_history 可以作為很好的切入點，例如通過關(guān)聯(lián)dba_hist_sqltext獲得執(zhí)行文本，通過關(guān)聯(lián)dba_hist_sql_plan獲得執(zhí)行計劃樹等，有時候?qū)⒅苯诱业皆斐傻却录脑獌础?/span>
RAC中常見的爭用和解決方法：
① Sequence and index contention
Sequence是RAC中容易引起爭用的一個地方,尤其是以sequence作索引，在高并發(fā)的多節(jié)點insert情況下極易引起索引塊的爭用以及CR副本的跨實例傳輸。
需要盡量增大Sequence的cache值并設(shè)置序列為noorder。
② undo block considerations
RAC下CR的構(gòu)造比單實例成本要高，如果一個block中的活動事務(wù)分布在幾個實例上，需要將幾個實例上的undo合并構(gòu)造所需要的CR，尤其是高并發(fā)的有索引鍵的插入，容易造成undo block的爭用。
盡量使用小事務(wù)處理。
③ HW considerations
跨節(jié)點的高并發(fā)insert會造成高水位線的爭用，采用更大的extent/采用ASSM和分區(qū)技術(shù)能減緩這一爭用。
④ Hot Block
全局熱點塊問題對RAC系統(tǒng)的影響巨大，盡量減少塊跨實例的并發(fā)更改,適當采用分區(qū)可以緩解該爭用。
一個良好的應(yīng)用設(shè)計是RAC發(fā)揮功力的重要前提，根據(jù)不同的節(jié)點部署不同的應(yīng)用，能有效的減少全局資源的爭用，對RAC性能的穩(wěn)定也相當重要。
服務(wù)硬件：指提供計算服務(wù)的硬件，比如 PC 機、PC 服務(wù)器。
服務(wù)實體：服務(wù)實體通常指服務(wù)軟體和服務(wù)硬體。
節(jié)點（node）：運行 Heartbeat 進程的一個獨立主機稱為節(jié)點，節(jié)點是 HA 的核心組成部分，每個節(jié)點上運行著操作系統(tǒng)和Heartbeat 軟件服務(wù)。
資源（resource）：資源是一個節(jié)點可以控制的實體，當節(jié)點發(fā)生故障時，這些資源能夠被其他節(jié)點接管。如： 磁盤分區(qū)、文件系統(tǒng)、IP 地址、應(yīng)用程序服務(wù)、共享存儲
事件（event）：事件也就是集群中可能發(fā)生的事情，例如節(jié)點系統(tǒng)故障、網(wǎng)絡(luò)連通故障、網(wǎng)卡故障和應(yīng)用程序故障等。這些事件都會導(dǎo)致節(jié)點的資源發(fā)生轉(zhuǎn)移，HA 的測試也是基于這些事件進行的。
集群（cluster）就是一組計算機，它們作為一個整體向用戶提供一組網(wǎng)絡(luò)資源，這些單個的計算機系統(tǒng)就是集群的節(jié)點（node）。集群提供了以下關(guān)鍵的特性。
(一) 可擴展性。集群的性能不限于單一的服務(wù)實體，新的服務(wù)實體可以動態(tài)的加入到集群，從而增強集群的性能。
(二) 高可用性。集群通過服務(wù)實體冗余使客戶端免于輕易遭遇到“out of service”警告。當一臺節(jié)點服務(wù)器發(fā)生故障的時候，這臺服務(wù)器上所運行的應(yīng)用程序?qū)⒃诹硪还?jié)點服務(wù)器上被自動接管。消除單點故障對于增強數(shù)據(jù)可用性、可達性和可靠性是非常重要的。
(三) 負載均衡。負載均衡能把任務(wù)比較均勻的分布到集群環(huán)境下的計算和網(wǎng)絡(luò)資源，以便提高數(shù)據(jù)吞吐量。
(四) 錯誤恢復(fù)。如果集群中的某一臺服務(wù)器由于故障或者維護需要而無法使用，資源和應(yīng)用程序?qū)⑥D(zhuǎn)移到可用的集群節(jié)點上。這種由于某個節(jié)點中的資源不能工作，另一個可用節(jié)點中的資源能夠透明的接管并繼續(xù)完成任務(wù)的過程叫做錯誤恢復(fù)。
分布式與集群的聯(lián)系與區(qū)別如下：
(一) 分布式是指將不同的業(yè)務(wù)分布在不同的地方。
(二) 而集群指的是將幾臺服務(wù)器集中在一起，實現(xiàn)同一業(yè)務(wù)。
(三) 分布式的每一個節(jié)點，都可以做集群，而集群并不一定就是分布式的。而分布式，從狹義上理解，也與集群差不多，但是它的組織比較松散，不像集群，有一定組織性，一臺服務(wù)器宕了，其他的服務(wù)器可以頂上來。分布式的每一個節(jié)點，都完成不同的業(yè)務(wù)，一個節(jié)點宕了，這個業(yè)務(wù)就不可訪問了。
集群主要分成三大類：
HA：高可用集群（High Availability Cluster）。
LBC：負載均衡集群/負載均衡系統(tǒng)（Load Balance Cluster）
HPC：科學計算集群（High Performance Computing Cluster）/高性能計算（High Performance Computing）集群。
隨著經(jīng)濟的高速發(fā)展，企業(yè)規(guī)模的迅猛擴張，企業(yè)用戶的數(shù)量、數(shù)據(jù)量的爆炸式增長，對數(shù)據(jù)庫提出了嚴峻的考驗。對于所有的數(shù)據(jù)庫而言，除了記錄正確的處理結(jié)果之外，還面臨著以下幾方面的挑戰(zhàn)。
在數(shù)據(jù)庫上，組建集群也是同樣的道理，主要有以下幾個原因：
(一) 伴隨著企業(yè)的成長，業(yè)務(wù)量提高，數(shù)據(jù)庫的訪問量和數(shù)據(jù)量快速增長，其處理能力和計算速度也相應(yīng)增大，使得單一的設(shè)備根本無法承擔。
(二) 在以上情況下，若扔掉現(xiàn)有設(shè)備，做大量的硬件升級，勢必造成現(xiàn)有資源的浪費，而且下一次業(yè)務(wù)量提升時，又將面臨再一次硬件升級的高額投入。于是，人們希望通過幾個中小型服務(wù)器組建集群，實現(xiàn)數(shù)據(jù)庫的負載均衡及持續(xù)擴展；在需要更高數(shù)據(jù)庫處理速度時，只要簡單的增加數(shù)據(jù)庫服務(wù)器就可以得到擴展。
(三) 數(shù)據(jù)庫作為信息系統(tǒng)的核心，起著非常重要的作用，單一設(shè)備根本無法保證系統(tǒng)的下持續(xù)運行，若發(fā)生系統(tǒng)故障，將嚴重影響系統(tǒng)的正常運行，甚至帶來巨大的經(jīng)濟損失。于是，人們希望通過組建數(shù)據(jù)庫集群，實現(xiàn)數(shù)據(jù)庫的高可用，當某節(jié)點發(fā)生故障時，系統(tǒng)會自動檢測并轉(zhuǎn)移故障節(jié)點的應(yīng)用，保證數(shù)據(jù)庫的持續(xù)工作。
(四) 企業(yè)的數(shù)據(jù)庫保存著企業(yè)的重要信息，一些核心數(shù)據(jù)甚至關(guān)系著企業(yè)的命脈，單一設(shè)備根本無法保證數(shù)據(jù)庫的安全性，一旦發(fā)生丟失，很難再找回來。于是，人們希望通過組建數(shù)據(jù)庫集群，實現(xiàn)數(shù)據(jù)集的冗余，通過備份數(shù)據(jù)來保證安全性。
數(shù)據(jù)庫集群技術(shù)是將多臺服務(wù)器聯(lián)合起來組成集群來實現(xiàn)綜合性能優(yōu)于單個大型服務(wù)器的技術(shù)，這種技術(shù)不但能滿足應(yīng)用的需要，而且大幅度的節(jié)約了投資成本。數(shù)據(jù)庫集群技術(shù)分屬兩類體系：基于數(shù)據(jù)庫引擎的集群技術(shù)和基于數(shù)據(jù)庫網(wǎng)關(guān)（中間件）的集群技術(shù)。在數(shù)據(jù)庫集群產(chǎn)品方面，其中主要包括基于數(shù)據(jù)庫引擎的集群技術(shù)的 Oracle RAC、Microsoft MSCS、IBM DB2UDB、Sybase ASE，以及基于數(shù)據(jù)庫網(wǎng)關(guān)（中間件）的集群技術(shù)的 ICX-UDS 等產(chǎn)品。
一般來講，數(shù)據(jù)庫集群軟件側(cè)重的方向和試圖解決的問題劃分為三大類：
只有 Oracle RAC 能實現(xiàn)以上三方面
(一) Oracle RAC：
其架構(gòu)的最大特點是共享存儲架構(gòu)（Shared-storage），整個 RAC 集群是建立在一個共享的存儲設(shè)備之上的，節(jié)點之間采用高速網(wǎng)絡(luò)互聯(lián)。OracleRAC 提供了非常好的高可用特性，比如負載均衡和應(yīng)用透明切塊（TAF），其最大的優(yōu)勢在于對應(yīng)用完全透明，應(yīng)用無需修改便可切換到RAC 集群。但是RAC 的可擴展能力有限，首先因為整個集群都依賴于底層的共享存儲，所以共享存儲的 I/O 能力和可用性決定了整個集群的可以提供的能力，對于 I/O 密集型的應(yīng)用，這樣的機制決定后續(xù)擴容只能是 Scale up（向上擴展）類型，對于硬件成本、開發(fā)人員的要求、維護成本都相對比較高。Oracle顯然也意識到了這個問題，在 Oracle 的 MAA（Maximum Availability Architecture）架構(gòu)中，采用 ASM 來整合多個存儲設(shè)備的能力，使得 RAC 底層的共享存儲設(shè)備具備線性擴展的能力，整個集群不再依賴于大型存儲的處理能力和可用性。
RAC 的另外一個問題是，隨著節(jié)點數(shù)的不斷增加，節(jié)點間通信的成本也會隨之增加，當?shù)侥硞€限度時，增加節(jié)點可能不會再帶來性能上的提高，甚至可能造成性能下降。這個問題的主要原因是 Oracle RAC 對應(yīng)用透明，應(yīng)用可以連接集群中的任意節(jié)點進行處理，當不同節(jié)點上的應(yīng)用爭用資源時，RAC 節(jié)點間的通信開銷會嚴重影響集群的處理能力。所以對于使用 ORACLE RAC 有以下兩個建議：
基于這個原因，Oracle RAC 通常在 DSS 環(huán)境（決策支持系統(tǒng)Decision Support System ，簡稱DSS)中可以做到很好的擴展性，因為 DSS 環(huán)境很容易將不同的任務(wù)分布在不同計算節(jié)點上，而對于 OLTP 應(yīng)用（On-Line Transaction Processing聯(lián)機事務(wù)處理系統(tǒng)），Oracle RAC 更多情況下用來提高可用性，而不是為了提高擴展性。
(二) MySQL Cluster
MySQL cluster 和 Oracle RAC 完全不同，它采用 無共享架構(gòu)Shared nothing（shared nothing architecture）。整個集群由管理節(jié)點(ndb_mgmd)，處理節(jié)點(mysqld)和存儲節(jié)點(ndbd)組 成，不存在一個共享的存儲設(shè)備。MySQL cluster 主要利用了 NDB 存儲引擎來實現(xiàn)，NDB 存儲引擎是一個內(nèi)存式存儲引擎，要求數(shù)據(jù)必須全部加載到內(nèi)存之中。數(shù)據(jù)被自動分布在集群中的不同存 儲節(jié)點上，每個存儲節(jié)點只保存完整數(shù)據(jù)的一個分片(fragment)。同時，用戶可以設(shè)置同一份數(shù)據(jù)保存在多個不同的存儲節(jié)點上，以保證單點故障不會造 成數(shù)據(jù)丟失。MySQL cluster 主要由 3 各部分組成：
這樣的分層也是與 MySQL 本身把 SQL 處理和存儲分開的架構(gòu)相關(guān)系的。MySQL cluster 的優(yōu)點在于其是一個分布式的數(shù)據(jù)庫集群，處理節(jié)點和存儲節(jié)點都可以線性增加，整個集群沒有單點故障，可用性和擴展性都可以做到很高，更適合 OLTP 應(yīng)用。但是它的問題在于：
雖然 MySQL cluster 目前性能還不理想，但是 share nothing 的架構(gòu)一定是未來的趨勢，Oracle 接手 MySQL之后，也在大力發(fā)展 MySQL cluster，我對 MySQL cluster 的前景抱有很大的期待。
(三) 分布式數(shù)據(jù)庫架構(gòu)
MySQL 5 之后才有了數(shù)據(jù)表分區(qū)功能（Sharding）， Sharding 不是一個某個特定數(shù)據(jù)庫軟件附屬的功能，而是在具體技術(shù)細節(jié)之上的抽象處理，是水平擴展(Scale Out，亦或橫向擴展、向外擴展)的解決方案，其主要目的是為突破單節(jié)點數(shù)據(jù)庫服務(wù)器的 I/O 能力限制，解決數(shù)據(jù)庫擴展性問題。比如 Oracle 的 RAC 是采用共享存儲機制，對于 I/O 密集型的應(yīng)用，瓶頸很容易落在存儲上，這樣的機制決定后續(xù)擴容只能是 Scale Up（向上擴展） 類型，對于硬件成本、開發(fā)人員的要求、維護成本都相對比較高。Sharding 基本上是針對開源數(shù)據(jù)庫的擴展性解決方案，很少有聽說商業(yè)數(shù)據(jù)庫進行 Sharding 的。目前業(yè)界的趨勢基本上是擁抱 Scale Out，逐漸從 Scale Up 中解放出來。
Sharding 架構(gòu)的優(yōu)勢在于，集群擴展能力很強，幾乎可以做到線性擴展，而且整個集群的可用性也很高，部分節(jié)點故障，不會影響其他節(jié)點提供服務(wù)。Sharding 原理簡單，容易實現(xiàn)，是一種非常好的解決數(shù)據(jù)庫擴展性的方案。Sharding 并不是數(shù)據(jù)庫擴展方案的銀彈，也有其不適合的場景，比如處理事務(wù)型的應(yīng)用它可能會造成應(yīng)用架構(gòu)復(fù)雜或者限制系統(tǒng)的功能，這也是它的缺陷所在。讀寫分離是架構(gòu)分布式系統(tǒng)的一個重要思想。不少系統(tǒng)整體處理能力并不能同業(yè)務(wù)的增長保持同步，因此勢必會帶來瓶頸，單純的升級硬件并不能一勞永逸。針對業(yè)務(wù)類型特點，需要從架構(gòu)模式進行一系列的調(diào)整，比如業(yè)務(wù)模塊的分割，數(shù)據(jù)庫的拆分等等。集中式和分布式是兩個對立的模式，不同行業(yè)的應(yīng)用特點也決定了架構(gòu)的思路。如互聯(lián)網(wǎng)行業(yè)中一些門戶站點，出于技術(shù)和成本等方面考慮，更多的采用開源的數(shù)據(jù)庫產(chǎn)品(如 MYSQL)，由于大部分是典型的讀多寫少的請求，因此為 MYSQL 及其復(fù)制技術(shù)大行其道提供了條件。而相對一些傳統(tǒng)密集交易型的行業(yè)，比如電信業(yè)、金融業(yè)等，考慮到單點處理能力和可靠性、穩(wěn)定性等問題，可能更多的采用商用數(shù)據(jù)庫，比如DB2、Oracle 等。就數(shù)據(jù)庫層面來講，大部分傳統(tǒng)行業(yè)核心庫采用集中式的架構(gòu)思路，采用高配的小型機做主機載體，因為數(shù)據(jù)庫本身和主機強大的處理能力，數(shù)據(jù)庫端一般能支撐業(yè)務(wù)的運轉(zhuǎn)，因此，Oracle 讀寫分離式的架構(gòu)相對MYSQL 來講，相對會少。讀寫分離架構(gòu)利用了數(shù)據(jù)庫的復(fù)制技術(shù)，將讀和 寫分布在不同的處理節(jié)點上，從而達到提高可用性和擴展性的目的。最通常的做法是利用 MySQL Replication 技術(shù)，Master DB 承擔寫操作，將數(shù)據(jù)變化復(fù)制到多臺 Slave DB上，并承擔讀的操作。這種架構(gòu)適合 read-intensive 類型的應(yīng)用，通過增加 Slave DB 的數(shù)量，讀的性能可以線性增長。為了避免 Master DB 的單點故障，集群一般都會采用兩臺 Master DB 做雙機熱備，所以整個集群的讀和寫的可用性都非常高。除了 MySQL，Oracle 從 11g 開始提供 Active Standby 的功能，也具備了實現(xiàn)讀寫分離架構(gòu)的基礎(chǔ)。讀寫分離架構(gòu)的缺陷在于，不管是 Master 還是 Slave，每個節(jié)點都必須保存完整的數(shù)據(jù)，如 果在數(shù)據(jù)量很大的情況下，集群的擴展能力還是受限于單個節(jié)點的存儲能力，而且對于 Write-intensive 類型的應(yīng)用，讀寫分離架構(gòu)并不適合。
采用 Oracle 讀寫分離的思路，Writer DB 和 Reader DB 采用日志復(fù)制軟件實現(xiàn)實時同步； Writer DB 負責交易相關(guān)的實時查詢和事務(wù)處理，Reader DB 負責只讀接入，處理一些非實時的交易明細,報表類的匯總查詢等。同時，為了滿足高可用性和擴展性等要求，對讀寫端適當做外延，比如 Writer DB 采用 HA 或者 RAC 的架構(gòu)模式，目前，除了數(shù)據(jù)庫廠商的 集群產(chǎn)品以外，解決數(shù)據(jù)庫擴展能力的方法主要有兩個：數(shù)據(jù)分片和讀寫分離。數(shù)據(jù)分片(Sharding)的原理就是將數(shù)據(jù)做水平切分，類似于 hash 分區(qū) 的原理，通過應(yīng)用架構(gòu)解決訪問路由和Reader DB 可以采用多套，通過負載均衡或者業(yè)務(wù)分離的方式，有效分擔讀庫的壓力。
對于 Shared-nothing 的數(shù)據(jù)庫架構(gòu)模式，核心的一個問題就是讀寫庫的實時同步；另外，雖然 Reader DB只負責業(yè)務(wù)查詢，但并不代表數(shù)據(jù)庫在功能上是只讀的。只讀是從應(yīng)用角度出發(fā)，為了保證數(shù)據(jù)一致和沖突考慮，因為查詢業(yè)務(wù)模塊可能需要涉及一些中間處理，如果需要在數(shù)據(jù)庫里面處理(取決與應(yīng)用需求和設(shè)計)，所以Reader DB 在功能上仍然需要可寫。下面談一下數(shù)據(jù)同步的技術(shù)選型問題：
能實現(xiàn)數(shù)據(jù)實時同步的技術(shù)很多，基于 OS 層(例如 VERITAS VVR)，基于存儲復(fù)制(中高端存儲大多都支持)，基于應(yīng)用分發(fā)或者基于數(shù)據(jù)庫層的技術(shù)。因為數(shù)據(jù)同步可能并不是單一的 DB 整庫同步，會涉及到業(yè)務(wù)數(shù)據(jù)選擇以及多源整合等問題，因此 OS 復(fù)制和存儲復(fù)制多數(shù)情況并不適合做讀寫分離的技術(shù)首選?；谌罩镜?Oracle 復(fù)制技術(shù)，Oracle 自身組件可以實現(xiàn)，同時也有成熟的商業(yè)軟件。選商業(yè)的獨立產(chǎn)品還是 Oracle 自身的組件功能，這取決于多方面的因素。比如團隊的相應(yīng)技術(shù)運維能力、項目投入成本、業(yè)務(wù)系統(tǒng)的負載程度等。
采用 Oracle 自身組件功能，無外乎 Logical Standby、Stream 以及 11g 的 Physical Standby(Active Data Guard)，對比來說，Stream 最靈活，但最不穩(wěn)定，11g Physical Standby 支持恢復(fù)與只讀并行，但由于并不是日志的邏輯應(yīng)用機制，在讀寫分離的場景中最為局限。如果技術(shù)團隊對相關(guān)技術(shù)掌握足夠充分，而選型方案的處理能力又能支撐數(shù)據(jù)同步的要求，采用 Oracle 自身的組件完全可行。選擇商業(yè)化的產(chǎn)品，更多出于穩(wěn)定性、處理能力等考慮。市面上成熟的 Oracle 復(fù)制軟件也無外乎幾種，無論是老牌的 Shareplex，還是本土 DSG 公司的 RealSync 和九橋公司的 DDS，或是 Oracle 新貴 Goldengate，都是可供選擇的目標。隨著 GoldenGate 被 Oracle 收購和推廣，個人認為 GoldenGate 在容災(zāi)、數(shù)據(jù)分發(fā)和同步方面將大行其道。當然，架構(gòu)好一個可靠的分布式讀寫分離的系統(tǒng)，還需要應(yīng)用上做大量設(shè)計，不在本文討論范圍內(nèi)。
(四) CAP 和 BASE 理論
分布式領(lǐng)域 CAP 理論：
定理：任何分布式系統(tǒng)只可同時滿足二點，沒法三者兼顧。
忠告：架構(gòu)師不要將精力浪費在如何設(shè)計能滿足三者的完美分布式系統(tǒng)，而是應(yīng)該進行取舍。
關(guān)系數(shù)據(jù)庫的 ACID 模型擁有 高一致性 + 可用性 很難進行分區(qū)：
(五) 跨數(shù)據(jù)庫事務(wù)
2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，也就是說傳統(tǒng)關(guān)系型數(shù)據(jù)庫要想實現(xiàn)一個分布式數(shù)據(jù)庫集群非常困難，關(guān)系型數(shù)據(jù)庫的擴展能力十分有限。而近年來不斷發(fā)展壯大的 NoSQL（非關(guān)系型的數(shù)據(jù)庫）運動，就是通過犧牲強一致性，采用 BASE 模型，用最終一致性的思想來設(shè)計分布式系統(tǒng)，從而使得系統(tǒng)可以達到很高的可用性和擴展性。那么，有沒有可能實現(xiàn)一套分布式數(shù)據(jù)庫集群，既保證可用性和一致性，又可以提供很好的擴展能力呢？
BASE 思想的主要實現(xiàn)有按功能劃分數(shù)據(jù)庫 sharding 碎片BASE 思想主要強調(diào)基本的可用性，如果你需要 High 可用性，也就是純粹的高性能，那么就要以一致性或容錯性為犧牲，BASE 思想的方案在性能上還是有潛力可挖的。
目前，已經(jīng)有很多分布式數(shù)據(jù)庫的產(chǎn)品，但是絕大部分是面向 DSS 類型的應(yīng)用，因為相比較 OLTP 應(yīng)用，DSS 應(yīng)用更容易做到分布式擴展，比如基于 PostgreSQL 發(fā)展的 Greenplum，就很好的解決了可用性和擴展性的問題，并且提供了很強大的并行計算能力。對于 OLTP 應(yīng)用，業(yè)務(wù)特點決定其要求：高可用性，一致性， 響應(yīng)時間短，支持事務(wù)和 join 等等。數(shù)據(jù)庫和 NoSQL當越來越多的 NoSQL 產(chǎn)品涌現(xiàn)出來，它們具備很多關(guān)系型數(shù)據(jù)庫所不具備的特性，在可用性和擴展性方面都可以做到很好。
第一，NoSQL 的應(yīng)用場景非常局限，某個類型的 NoSQL 僅僅針對特定類型的應(yīng)用場景而設(shè)計。而關(guān)系型數(shù)據(jù)庫則要通用的多，使用 NoSQL 必須搞清楚自己的應(yīng)用場景是否適合。
第二，利用關(guān)系型數(shù)據(jù)庫配合應(yīng)用架構(gòu)， 比如 Sharding 和讀寫分離技術(shù)，同樣可以搭建出具備高可用和擴展性的分布式數(shù)據(jù)庫集群。
第三，關(guān)系型數(shù)據(jù)庫廠商依然很強大，全世界有大量的 用戶，需求必然會推動新的產(chǎn)品問世。
第四，硬件的發(fā)展日新月異，比如閃存的技術(shù)的不斷成熟，未來閃存可以作為磁盤與內(nèi)存之間的 cache，或者完 全替代磁盤。而內(nèi)存價格越來越低，容量越來越大，In-memory cache 或 database 的應(yīng)用越來越廣泛，可以給應(yīng)用帶來數(shù)量級的性能提升。數(shù)據(jù)庫面臨的 IO 問題將被極大改善。
1 RAC（Real Application Clusters）
多個Oracle服務(wù)器組成一個共享的Cache，而這些Oracle服務(wù)器共享一個基于網(wǎng)絡(luò)的存儲。這個系統(tǒng)可以容忍單機/或是多機失敗。不過系統(tǒng)內(nèi)部的多個節(jié)點需要高速網(wǎng)絡(luò)互連，基本上也就是要全部東西放在在一個機房內(nèi)，或者說一個數(shù)據(jù)中心內(nèi)。如果機房出故障，比如網(wǎng)絡(luò)不通，那就壞了。所以僅僅用RAC還是滿足不了一般互聯(lián)網(wǎng)公司的重要業(yè)務(wù)的需要，重要業(yè)務(wù)需要多機房來容忍單個機房的事故。
2 Data Guard.（最主要的功能是冗災(zāi)）
Data Guard這個方案就適合多機房的。某機房一個production的數(shù)據(jù)庫，另外其他機房部署standby的數(shù)據(jù)庫。Standby數(shù)據(jù)庫分物理的和邏輯的。物理的standby數(shù)據(jù)庫主要用于production失敗后做切換。而邏輯的standby數(shù)據(jù)庫則在平時可以分擔production數(shù)據(jù)庫的讀負載。
3 MAA
MAA(Maximum Availability Architecture)其實不是獨立的第三種，而是前面兩種的結(jié)合，來提供最高的可用性。每個機房內(nèi)部署RAC集群，多個機房間用Data Guard同步。
共享存儲文件系統(tǒng)（NFS），或甚至集群文件系統(tǒng)（如：OCFS2）主要被用于存儲區(qū)域網(wǎng)絡(luò)（所有節(jié)點直接訪問共享文件系統(tǒng)上存儲器），這就使得節(jié)點失效而不影響來自其他節(jié)點對文件系統(tǒng)的訪問，通常，共享磁盤文件系統(tǒng)用于高可用集群。
Oracle RAC的核心是共享磁盤子系統(tǒng)，集群中所有節(jié)點必須能夠訪問所有數(shù)據(jù)、重做日志文件、控制文件和參數(shù)文件，數(shù)據(jù)磁盤必須是全局可用的，允許所有節(jié)點訪問數(shù)據(jù)庫，每個節(jié)點有它自己的重做日志和控制文件，但是其他節(jié)點必須能夠訪問它們以便在那個節(jié)點出現(xiàn)系統(tǒng)故障時能夠恢復(fù)。
Oracle RAC 運行于集群之上，為 Oracle 數(shù)據(jù)庫提供了最高級別的可用性、可伸縮性和低成本計算能力。如果集群內(nèi)的一個節(jié)點發(fā)生故障，Oracle 將可以繼續(xù)在其余的節(jié)點上運行。Oracle 的主要創(chuàng)新是一項稱為高速緩存合并的技術(shù)。高速緩存合并使得集群中的節(jié)點可以通過高速集群互聯(lián)高效地同步其內(nèi)存高速緩存，從而最大限度地低降低磁盤 I/O。高速緩存最重要的優(yōu)勢在于它能夠使集群中所有節(jié)點的磁盤共享對所有數(shù)據(jù)的訪問。數(shù)據(jù)無需在節(jié)點間進行分區(qū)。Oracle 是唯一提供具備這一能力的開放系統(tǒng)數(shù)據(jù)庫的廠商。其它聲稱可以運行在集群上的數(shù)據(jù)庫軟件需要對數(shù)據(jù)庫數(shù)據(jù)進行分區(qū)，顯得不切實際。企業(yè)網(wǎng)格是未來的數(shù)據(jù)中心，構(gòu)建于由標準化商用組件構(gòu)成的大型配置之上，其中包括：處理器、網(wǎng)絡(luò)和存儲器。Oracle RAC 的高速緩存合并技術(shù)提供了最高等級的可用性和可伸縮性。Oracle 數(shù)據(jù)庫 10g 和 OracleRAC 10g 顯著降低了運營成本，增強了靈活性，從而賦予了系統(tǒng)更卓越的適應(yīng)性、前瞻性和靈活性。動態(tài)提供節(jié)點、存儲器、CPU 和內(nèi)存可以在實現(xiàn)所需服務(wù)級別的同時，通過提高的利用率不斷降低成本。
Oracle RAC 10g 在 Oracle 數(shù)據(jù)庫 10g 運行的所有平臺上提供了一個完整集成的集群件管理解決方案。這一集群件功能包括集群連接、消息處理服務(wù)和鎖定、集群控制和恢復(fù)，以及一個工作負載管理框架（將在下文探討）。Oracle RAC 10g 的集成集群件管理具有以下優(yōu)勢：
(一) 成本低。Oracle 免費提供這一功能。
(二) 單一廠商支持。消除了相互推諉的問題。
(三) 安裝、配置和持續(xù)維護更簡單。Oracle RAC 10g 集群件使用標準 Oracle 數(shù)據(jù)庫管理工具進行安裝、配置和維護。這一過程無須其它的集成步驟。
(四) 所有平臺，質(zhì)量始終如一。與第三方產(chǎn)品相比，Oracle 對新軟件版本進行了更嚴格的測試。
(五) 所有平臺，功能始終如一。例如，一些第三方集群件產(chǎn)品限制了集群內(nèi)可以支持的節(jié)點的數(shù)量。借助Oracle RAC 10g，所有平臺可以支持多達 64 個節(jié)點。用戶還可以在所有平臺上獲得一致的響應(yīng)體驗，從而有效解決了高可用性挑戰(zhàn)，包括服務(wù)器節(jié)點故障、互連故障以及 I/O 隔離現(xiàn)象等。
(六) 支持高級功能。這包括集成監(jiān)視和通知功能，從而在發(fā)生故障時，在數(shù)據(jù)庫和應(yīng)用層之間實現(xiàn)快速協(xié)調(diào)的恢復(fù)。
RAC 是 Oracle 數(shù)據(jù)庫的一個群集解決方案，是有著兩個或者兩個以上的數(shù)據(jù)庫節(jié)點協(xié)調(diào)運作能力的。如下圖所示的 RAC 結(jié)構(gòu)圖：
集群管理器（Cluster Manager）在集群系統(tǒng)中對其他各個模塊進行整合，通過高速的內(nèi)連接來提供群集節(jié)點之間的通信。各節(jié)點之間內(nèi)連接使用心跳線互聯(lián)，心跳線上的信息功能確定群集邏輯上的節(jié)點成員信息和節(jié)點更新情況，以及節(jié)點在某個時間點的運行狀態(tài)，保證群集系統(tǒng)正常運行。通信層管理節(jié)點之間的通信。它的職責是配置，互聯(lián)群集中節(jié)點信息，在群集管理器中使用由心跳機制產(chǎn)生的信息，由通信層負責傳輸，確保信息的正確到達。還有一些群集監(jiān)視進程不斷驗證系統(tǒng)的不同領(lǐng)域運行狀況。例如，心跳監(jiān)測不斷驗證的心跳機制的運作是否良好。在一個應(yīng)用環(huán)境當中，所有的服務(wù)器使用和管理同一個數(shù)據(jù)庫，目的是分散每一臺服務(wù)器的工作量。硬件上至少需要兩臺以上的服務(wù)器，而且還需要一個共享存儲設(shè)備；同時還需要兩類軟件，一類是集群軟件，另外一類就是 Oracle 數(shù)據(jù)庫中的 RAC 組件。同時所有服務(wù)器上的 OS 都應(yīng)該是同一類 OS，根據(jù)負載均衡的配置策略，當一個客戶端發(fā)送請求到某一臺服務(wù)的 listener 后，這臺服務(wù)器根據(jù)負載均衡策略，會把請求發(fā)送給本機的 RAC組件處理，也可能會發(fā)送給另外一臺服務(wù)器的 RAC 組件處理，處理完請求后，RAC 會通過群集軟件來訪問共享存儲設(shè)備。邏輯結(jié)構(gòu)上看，每一個參加群集的節(jié)點有一個獨立的實例，這些實例訪問同一個數(shù)據(jù)庫。節(jié)點之間通過集群軟件的通信層（Communication Layer）來進行通信。同時為了減少 I/O 的消耗，存在一個全局緩存服務(wù)，因此每一個數(shù)據(jù)庫的實例，都保留了一份相同的數(shù)據(jù)庫 cache。RAC 中的特點如下：
在 Oracle9i 之前，RAC 稱為 OPS（Oracle Parallel Server）。RAC 與 OPS 之間的一個較大區(qū)別是，RAC 采用了Cache Fusion（高緩存合并）技術(shù)，節(jié)點已經(jīng)取出的數(shù)據(jù)塊更新后沒有寫入磁盤前，可以被另外一個節(jié)點更新，然后以最后的版本寫入磁盤。在 OPS 中，節(jié)點間的數(shù)據(jù)請求需要先將數(shù)據(jù)寫入磁盤，然后發(fā)出請求的節(jié)點才可以讀取該數(shù)據(jù)。使用 Cache Fusion 時，RAC 的各個節(jié)點間數(shù)據(jù)緩沖區(qū)通過高速、低延遲的內(nèi)部網(wǎng)絡(luò)進行數(shù)據(jù)塊的傳輸。下圖是一個典型的 RAC 對外服務(wù)的示意圖，一個 Oracle RAC Cluster 包含了如下的部分
Oracle RAC 有一些自己獨特的后臺進程，在單一實例中不發(fā)揮配置作用。如下圖所示，定義了一些 RAC 運行的后臺進程。這些后臺進程的功能描述如下。
（1）LMS（Global cache service processes 全局緩存服務(wù)進程）進程主要用來管理集群內(nèi)數(shù)據(jù)塊的訪問，并在不同實例的 Buffer Cache 中傳輸數(shù)據(jù)塊鏡像。直接從控制的實例的緩存復(fù)制數(shù)據(jù)塊，然后發(fā)送一個副本到請求的實例上。并保證在所有實例的 Buffer Cache 中一個數(shù)據(jù)塊的鏡像只能出現(xiàn)一次。LMS 進程靠著在實例中傳遞消息來協(xié)調(diào)數(shù)據(jù)塊的訪問，當一個實例請求數(shù)據(jù)塊時，該實例的 LMD 進程發(fā)出一個數(shù)據(jù)塊資源的請求，該請求指向主數(shù)據(jù)塊的實例的 LMD 進程，主實例的 LMD 進程和正在使用的實例的 LMD 進程釋放該資源，這時擁有該資源的實例的 LMS 進程會創(chuàng)建一個數(shù)據(jù)塊鏡像的一致性讀然后把該數(shù)據(jù)塊傳遞到請求該資源的實例的BUFFER CACHE 中。LMS 進程保證了在每一時刻只能允許一個實例去更新數(shù)據(jù)塊，并負責保持該數(shù)據(jù)塊的鏡像記錄（包含更新數(shù)據(jù)塊的狀態(tài) FLAG)。RAC 提供了 10 個 LMS 進程（0~9），該進程數(shù)量隨著節(jié)點間的消息傳遞的數(shù)據(jù)的增加而增加。（2）LMON（Lock Monitor Process，鎖監(jiān)控進程）是全局隊列服務(wù)監(jiān)控器，各個實例的 LMON 進程會定期通信，以檢查集群中各個節(jié)點的健康狀況，當某個節(jié)點出現(xiàn)故障時，負責集群重構(gòu)、GRD 恢復(fù)等操作，它提供的服務(wù)叫做 Cluster Group Service（CGS）。
LMON 主要借助兩種心跳機制來完成健康檢查。
(一) 節(jié)點間的網(wǎng)絡(luò)心跳（Network Heartbeat）：可以想象成節(jié)點間定時的發(fā)送 ping 包檢測節(jié)點狀態(tài)，如果能在規(guī)定時間內(nèi)收到回應(yīng)，就認為對方狀態(tài)正常。
(二) 通過控制文件的磁盤心跳（controlfile heartbeat）：每個節(jié)點的 CKPT 進程每隔 3 秒鐘更新一次控制文件的數(shù)據(jù)塊，這個數(shù)據(jù)塊叫做 Checkpoint Progress Record，控制文件是共享的，所以實例間可以互相檢查對方是否及時更新來判斷。
(三) LMD（the global enqueue service daemon，鎖管理守護進程）是一個后臺進程，也被稱為全局的隊列服務(wù)守護進程，因為負責對資源的管理要求來控制訪問塊和全局隊列。在每一個實例的內(nèi)部，LMD 進程管理輸入的遠程資源請求（即來自集群中其他實例的鎖請求）。此外，它還負責死鎖檢查和監(jiān)控轉(zhuǎn)換超時。
(四) LCK（the lock process，鎖進程）管理非緩存融合，鎖請求是本地的資源請求。LCK 進程管理共享資源的實例的資源請求和跨實例調(diào)用操作。在恢復(fù)過程中它建立一個無效鎖元素的列表，并驗證鎖的元素。由于處理過程中的 LMS 鎖管理的首要職能，只有一個單一的 LCK 進程存在每個實例中。
(五) DIAG（the diagnosability daemon，診斷守護進程）負責捕獲 RAC 環(huán)境中進程失敗的相關(guān)信息。并將跟蹤信息寫出用于失敗分析，DIAG 產(chǎn)生的信息在與 Oracle Support 技術(shù)合作來尋找導(dǎo)致失敗的原因方面是非常有用的。每個實例僅需要一個 DIAG 進程。
(六) GSD（the global service daemon，全局服務(wù)進程）與 RAC 的管理工具 dbca、srvctl、oem 進行交互，用來完成實例的啟動關(guān)閉等管理事務(wù)。為了保證這些管理工具運行正常必須在所有的節(jié)點上先start gsd，并且一個 GSD 進程支持在一個節(jié)點的多個 rac.gsd 進程位ORACLEHOME/bin目錄下，其log文件為ORACLEHOME/bin目錄下，其log文件為ORACLE_HOME/srvm/log/gsdaemon.log。GCS 和 GES 兩個進程負責通過全局資源目錄（Global Resource Directory GRD）維護每個數(shù)據(jù)的文件和緩存塊的狀態(tài)信息。當某個實例訪問數(shù)據(jù)并緩存了數(shù)據(jù)之后，集群中的其他實例也會獲得一個對應(yīng)的塊鏡像，這樣其他實例在訪問這些數(shù)據(jù)是就不需要再去讀盤了，而是直接讀取 SGA 中的緩存。GRD 存在于每個活動的 instance 的內(nèi)存結(jié)構(gòu)中，這個特點造成 RAC 環(huán)境的 SGA 相對于單實例數(shù)據(jù)庫系統(tǒng)的 SGA 要大。其他的進程和內(nèi)存結(jié)構(gòu)都跟單實例數(shù)據(jù)庫差別不大。
RAC 需要有共享存儲，獨立于實例之外的信息，如上面提到的ocr 和 votedisk 以及數(shù)據(jù)文件都存放在這個共享存儲里的。有OCFS、OCFS2、RAW、NFS、ASM 等這樣的一些存儲方式。OCFS（Oracle Cluster File System） 和 OCFS2 就是一個文件系統(tǒng)而已，和 NFS 一樣，提供一種集群環(huán)境中的共享存儲的文件系統(tǒng)。RAW 裸設(shè)備也是一種存儲方式，是 oracle11g 之前的版本中 RAC 支持的存儲方式，在 Oralce9i 之前，OPS/RAC的支持只能使用這樣的方式，也就是把共享存儲映射到 RAW Device，然后把 Oracle 需要的數(shù)據(jù)選擇 RAW device存儲，但是 RAW 相對于文件系統(tǒng)來說不直觀，不便于管理，而且 RAW Device 有數(shù)量的限制，RAW 顯然需要有新的方案來代替，這樣就有了 OCFS 這樣的文件系統(tǒng)。當然，這只是 Oracle 自己的實現(xiàn)的集文件系統(tǒng)而已，還有其他廠商提供的文件系統(tǒng)可以作為存儲的選擇方案。ASM 只是數(shù)據(jù)庫存儲的方案而已，并不是 cluster 的方案，所以這里 ASM 應(yīng)該是區(qū)別于 RAW 和 OCFS/OCFS2同一級別的概念，RAW 和 OCFS/OCFS2 不僅可以作為數(shù)據(jù)庫存儲的方案，同時也可以作為 Clusterware 里的存儲方案，是 CRS 里需要的 storage，而 ASM 僅作為數(shù)據(jù)庫的存儲而已，嚴格來說僅是 RAC 中的一個節(jié)點應(yīng)用（nodeapps）。ASM 對于 clusterware 安裝時需要的 ocr 和 votedisk 這兩項還不支持，畢竟 ASM 本身就需要一個實例，而 CRS 是完全在架構(gòu)之外的，這也就是為什么使用了 ASM 的方案，卻總還要加上 OCFS/OCFS2 和 RAW 其中的一個原因。各種 RAC 共享存儲方式的對比如下：
為了讓 RAC 中的所有實例能夠訪問數(shù)據(jù)庫，所有的 datafiles、control files、PFILE/Spfile 和 redo log files 必須保存在共享磁盤上，并且要都能被所有節(jié)點同時訪問，就涉及到裸設(shè)備和集群文件系統(tǒng)等。RAC database 在結(jié)構(gòu)上與單實例的不同之處：至少為每個實例多配置一個 redo 線程，比如：兩個實例組成的集群至少要 4 個 redo log group。每個實例兩個 redo group。另外要為每一個實例準備一個 UNDO 表空間。
1、redo 和 undo，每個實例在做數(shù)據(jù)庫的修改時誰用誰的 redo 和 undo 段，各自鎖定自己修改的數(shù)據(jù)，把不同實例的操作相對的獨立開就避免了數(shù)據(jù)不一致。后面就要考慮備份或者恢復(fù)時 redo log 和歸檔日志在這種情況下的特殊考慮了。
2、內(nèi)存和進程各個節(jié)點的實例都有自己的內(nèi)存結(jié)構(gòu)和進程結(jié)構(gòu).各節(jié)點之間結(jié)構(gòu)是基本相同的.通過 Cache Fusion（緩存融合）技術(shù)，RAC 在各個節(jié)點之間同步 SGA 中的緩存信息達到提高訪問速度的效果也保證了一致性。
OracleRAC 是多個單實例在配置意義上的擴展，實現(xiàn)由兩個或者多個節(jié)點（實例）使用一個共同的共享數(shù)據(jù)庫（例如，一個數(shù)據(jù)庫同時安裝多個實例并打開）。在這種情況下，每一個單獨的實例有它自己的 cpu 和物理內(nèi)存，也有自己的 SGA 和后臺進程。和傳統(tǒng)的 oracle 實例相比，在系統(tǒng)全局區(qū)（SYSTEM CLOBAL AREA,SGA）與后臺進程有著顯著的不同。最大的不同之處在于多了一個GRD,GRD內(nèi)存塊主要是記錄此rac有多少個集群數(shù)據(jù)庫與系統(tǒng)資源，同時也會記錄數(shù)據(jù)塊的相關(guān)信息，因為在 rac 架構(gòu)中，每個數(shù)據(jù)塊在每一個 SGA 中都有一份副本，而 rac 必須知道這些數(shù)據(jù)塊的位置，版本，分布以及目前的狀態(tài)，這些信息就存放在 GRD 中，但 GRD 只負責存放不負責管理，管理的責任則交給后臺進程 GCS 和 GES 來進行。Oracle 的多個實例訪問一個共同的共享數(shù)據(jù)庫。每個實例都有自己的 SGA、PGA 和后臺進程，這些后臺進程應(yīng)該是熟悉的，因為在 RAC 配置中，每個實例將需要這些后臺進程運行支撐的?？梢詮囊韵聨讉€方面了解 RAC工作原理和運行機制。
(一) SCN
SCN 是 Oracle 用來跟蹤數(shù)據(jù)庫內(nèi)部變化發(fā)生先后順序的機制，可以把它想象成一個高精度的時鐘，每個 Redo日志條目，Undo Data Block，Data Block 都會有 SCN 號。 Oracle 的Consistent-Read， Current-Read，Multiversion-Block 都是依賴 SCN 實現(xiàn)。在 RAC 中，有 GCS 負責全局維護 SCN 的產(chǎn)生，缺省用的是 Lamport SCN 生成算法，該算法大致原理是： 在所有節(jié)點間的通信內(nèi)容中都攜帶 SCN， 每個節(jié)點把接收到的 SCN 和本機的 SCN 對比，如果本機的 SCN 小，則調(diào)整本機的 SCN 和接收的一致，如果節(jié)點間通信不多，還會主動地定期相互通報。 故即使節(jié)點處于 Idle 狀態(tài)，還是會有一些 Redo log 產(chǎn)生。 還有一個廣播算法（Broadcast），這個算法是在每個 Commit 操作之后，節(jié)點要想其他節(jié)點廣播 SCN，雖然這種方式會對系統(tǒng)造成一定的負載，但是確保每個節(jié)點在 Commit 之后都能立即查看到 SCN.這兩種算法各有優(yōu)缺點，Lamport 雖然負載小，但是節(jié)點間會有延遲，廣播雖然有負載，但是沒有延遲。Oracle 10g RAC 缺省選用的是 BroadCast 算法，可以從 alert.log 日志中看到相關(guān)信息：Picked broadcast on commit scheme to generate SCNS
(二) RAC 的 GES/GCS 原理
全局隊列服務(wù)（GES）主要負責維護字典緩存和庫緩存的一致性。字典緩存是實例的 SGA 內(nèi)所存儲的對數(shù)據(jù)字典信息的緩存，用于高速訪問。由于該字典信息存儲在內(nèi)存中，因而在某個節(jié)點上對字典進行的修改（如DDL)必須立即被傳播至所有節(jié)點上的字典緩存。GES 負責處理上述情況，并消除實例間出現(xiàn)的差異。處于同樣的原因，為了分析影響這些對象的 SQL 語句，數(shù)據(jù)庫內(nèi)對象上的庫緩存鎖會被去掉。這些鎖必須在實例間進行維護，而全局隊列服務(wù)必須確保請求訪問相同對象的多個實例間不會出現(xiàn)死鎖。LMON、LCK 和 LMD 進程聯(lián)合工作來實現(xiàn)全局隊列服務(wù)的功能。GES 是除了數(shù)據(jù)塊本身的維護和管理（由 GCS 完成）之外，在 RAC 環(huán)境中調(diào)節(jié)節(jié)點間其他資源的重要服務(wù)。為了保證集群中的實例的同步，兩個虛擬服務(wù)將被實現(xiàn)：全局排隊服務(wù)（GES），它負責控制對鎖的訪問。
全局內(nèi)存服務(wù)（GCS)，控制對數(shù)據(jù)塊的訪問。GES 是 分布式鎖管理器(DLM)的擴展，它是這樣一個機制，可以用來管理 oracle 并行服務(wù)器的鎖和數(shù)據(jù)塊。在一個群集環(huán)境中，你需要限制對數(shù)據(jù)庫資源的訪問，這些資源在單 instance 數(shù)據(jù)庫中被 latches 或者 locks 來保護。比如說，在數(shù)據(jù)庫字典內(nèi)存中的對象都被隱性鎖所保護，而在庫高速緩存中的對象在被引用的時候，必須被 pin 所保護。在 RAC 群集中，這些對象代表了被全局鎖所保護的資源。GES 是一個完整的 RAC 組件，它負責和群集中的實例全局鎖進行溝通，每個資源有一個主節(jié)點實例，這個實例記錄了它當前的狀態(tài)。而且，資源的當前的狀態(tài)也記錄在所有對這個資源有興趣的實例上。GCS,是另一個 RAC 組件，負責協(xié)調(diào)不同實例間對數(shù)據(jù)塊的訪問。對這些數(shù)據(jù)塊的訪問以及跟新都記錄在全局目錄中（GRD）,這個全局目錄是一個虛擬的內(nèi)存結(jié)構(gòu)，在所有的實例中使用擴張。每個塊都有一個master實例，這個實例負責對GSD的訪問進行管理，GSD里記錄了這個塊的當前狀態(tài)信息。GCS 是 oracle 用來實施 Cache fusion 的機制。被 GCS 和 GES 管理的塊和鎖叫做資源。對這些資源的訪問必須在群集的多個實例中進行協(xié)調(diào)。這個協(xié)調(diào)在實例層面和數(shù)據(jù)庫層面都有發(fā)生。實例層次的資源協(xié)調(diào)叫做本地資源協(xié)調(diào)；數(shù)據(jù)庫層次的協(xié)調(diào)叫做全局資源協(xié)調(diào)。
本地資源協(xié)調(diào)的機制和單實例 oracle 的資源協(xié)調(diào)機制類似，包含有塊級別的訪問，空間管理，dictionary cache、library cache 管理，行級鎖，SCN 發(fā)生。全局資源協(xié)調(diào)是針對 RAC 的，使用了 SGA 中額外的內(nèi)存組件、算法和后臺進程。GCS 和 GES 從設(shè)計上就是在對應(yīng)用透明的情況下設(shè)計的。換一句話來說，你不需要因為數(shù)據(jù)庫是在 RAC上運行而修改應(yīng)用,在單實例的數(shù)據(jù)庫上的并行機制在 RAC 上也是可靠地。
支持 GCS 和 GES 的后臺進程使用私網(wǎng)心跳來做實例之間的通訊。這個網(wǎng)絡(luò)也被 Oracle 的 群集組件使用，也有可能被 群集文件系統(tǒng)（比如 OCFS)所使用。GCS 和 GES 獨立于 Oracle 群集組件而運行。但是，GCS 和GES 依靠 這些群集組件獲得群集中每個實例的狀態(tài)。如果這些信息不能從某個實例獲得，這個實例將被關(guān)閉。這個關(guān)閉操作的目的是保護數(shù)據(jù)庫的完整性，因為每個實例需要知道其他實例的情況，這樣可以更好的確定對數(shù)據(jù)庫的協(xié)調(diào)訪問。GES 控制數(shù)據(jù)庫中所有的 library cache 鎖和 dictionary cache 鎖。這些資源在單實例數(shù)據(jù)庫中是本地性的，但是到了 RAC 群集中變成了全局資源。全局鎖也被用來保護數(shù)據(jù)的結(jié)構(gòu)，進行事務(wù)的管理。一般說來，事務(wù)和表鎖 在 RAC 環(huán)境或是 單實例環(huán)境中是一致的。
Oracle 的各個層次使用相同的 GES 功能來獲得，轉(zhuǎn)化以及釋放資源。在數(shù)據(jù)庫啟動的時候，全局隊列的個數(shù)將被自動計算。GES 使用后臺進程 LMD0 和 LCK0 來執(zhí)行它的絕大多數(shù)活動。一般來說，各種進程和本地的 LMD0 后臺進程溝通來管理全局資源。本地的 LMD0 后臺進程與 別的實例上的 LMD0 進程進行溝通。
LCK0 后臺進程用來獲得整個實例需要的鎖。比如，LCK0 進程負責維護 dictionary cache 鎖。影子進程(服務(wù)進程） 與這些后臺進程通過 AST(異步陷阱）消息來通信。異步消息被用來避免后臺進程的阻塞，這些后臺進程在等待遠端實例的的回復(fù)的時候?qū)⒆枞?。后臺進程也能 發(fā)送 BAST(異步鎖陷阱）來鎖定進程，這樣可以要求這些進程把當前的持有鎖置為較低級限制的模式。資源是內(nèi)存結(jié)構(gòu)，這些結(jié)構(gòu)代表了數(shù)據(jù)庫中的組件，對這些組件的訪問必須為限制模式或者串行化模式。換一句話說，這個資源只能被一個進程或者一直實例并行訪問。如果這個資源當前是處于使用狀態(tài)，其他想訪問這個資源的進程必須在隊列中等待，直到資源變得可用。隊列是內(nèi)存結(jié)構(gòu)，它負責并行化對特殊資源的訪問。如果這些資源只被本地實例需求，那么這個隊列可以本地來獲得，而且不需要協(xié)同。但是如果這個資源被遠程實例所請求，那么本地隊列必須變成全球化。
在單機環(huán)境下，Oracle 是運行在 OS Kernel 之上的。 OS Kernel 負責管理硬件設(shè)備，并提供硬件訪問接口。Oracle 不會直接操作硬件，而是有 OS Kernel 代替它來完成對硬件的調(diào)用請求。在集群環(huán)境下， 存儲設(shè)備是共享的。OS Kernel 的設(shè)計都是針對單機的，只能控制單機上多個進程間的訪問。 如果還依賴 OS Kernel 的服務(wù)，就無法保證多個主機間的協(xié)調(diào)工作。 這時就需要引入額外的控制機制，在RAC 中，這個機制就是位于 Oracle 和 OS Kernel 之間的 Clusterware，它會在 OS Kernel 之前截獲請求，然后和其他結(jié)點上的 Clusterware 協(xié)商，最終完成上層的請求。在 Oracle 10G 之前，RAC 所需要的集群件依賴與硬件廠商，比如 SUN,HP,Veritas. 從 Oracle 10.1版本中，Oracle推出了自己的集群產(chǎn)品. Cluster Ready Service(CRS),從此 RAC 不在依賴與任何廠商的集群軟件。 在 Oracle 10.2版本中，這個產(chǎn)品改名為：Oracle Clusterware。所以我們可以看出， 在整個 RAC 集群中，實際上有 2 個集群環(huán)境的存在，一個是由 Clusterware 軟件組成的集群，另一個是由 Database 組成的集群。
(一) Clusterware 的主要進程
a) CRSD——負責集群的高可用操作，管理的 crs 資源包括數(shù)據(jù)庫、實例、監(jiān)聽、虛擬 IP，ons，gds 或者其他，操作包括啟動、關(guān)閉、監(jiān)控及故障切換。改進程由 root 用戶管理和啟動。crsd 如果有故障會導(dǎo)致系統(tǒng)重啟。
b) cssd，管理各節(jié)點的關(guān)系，用于節(jié)點間通信，節(jié)點在加入或離開集群時通知集群。該進程由 oracle 用戶運行管理。發(fā)生故障時 cssd 也會自動重啟系統(tǒng)。
c) oprocd – 集群進程管理 —Process monitor for the cluster. 用于保護共享數(shù)據(jù) IO fencing。
d) 僅在沒有使用 vendor 的集群軟件狀態(tài)下運行
e) evmd ：事件檢測進程，由 oracle 用戶運行管理
Cluster Ready Service（CRS，集群準備服務(wù)）是管理集群內(nèi)高可用操作的基本程序。Crs 管理的任何事物被稱之為資源，它們可以是一個數(shù)據(jù)庫、一個實例、一個監(jiān)聽、一個虛擬 IP（VIP）地址、一個應(yīng)用進程等等。CRS是根據(jù)存儲于 OCR 中的資源配置信息來管理這些資源的。這包括啟動、關(guān)閉、監(jiān)控及故障切換（start、stop、monitor 及 failover）操作。當一資源的狀態(tài)改變時，CRS 進程生成一個事件。當你安裝 RAC 時，CRS 進程監(jiān)控Oracle 的實例、監(jiān)聽等等，并在故障發(fā)生時自動啟動這些組件。默認情況下，CRS 進程會進行 5 次重啟操作，如果資源仍然無法啟動則不再嘗試。Event Management（EVM）：發(fā)布 CRS 創(chuàng)建事件的后臺進程。Oracle Notification Service（ONS）：通信的快速應(yīng)用通知（FAN：Fast Application Notification）事件的發(fā)布及訂閱服務(wù)。RACG：為 clusterware 進行功能擴展以支持 Oracle 的特定需求及復(fù)雜資源。它在 FAN 事件發(fā)生時執(zhí)行服務(wù)器端的調(diào)用腳本（server callout script）Process Monitor Daemon（OPROCD）：此進程被鎖定在內(nèi)存中，用于監(jiān)控集群（cluster）及提供 I/O 防護（I/Ofencing）。OPROCD 執(zhí)行它的檢查，停止運行，且如果喚醒超過它所希望的間隔時，OPROCD 重置處理器及重啟節(jié)點。一個 OPROCD 故障將導(dǎo)致 Clusterware 重啟節(jié)點。
Cluster Synchronization Service（CSS）：CSS 集群同步服務(wù)，管理集群配置，誰是成員、誰來、誰走，通知成員，是集群環(huán)境中進程間通信的基礎(chǔ)。同樣，CSS 也可以用于在單實例環(huán)境中處理 ASM 實例與常規(guī) RDBMS 實例之間的交互作用。在集群環(huán)境中，CSS 還提供了組服務(wù)，即關(guān)于在任意給定時間內(nèi)哪些節(jié)點和實例構(gòu)成集群的動態(tài)信息，以及諸如節(jié)點的名稱和節(jié)點靜態(tài)信息（這些信息在節(jié)點被加入或者移除時被修改）。CSS 維護集群內(nèi)的基本鎖功能（盡管大多數(shù)鎖有 RDBMS 內(nèi)部的集成分布式鎖管理來維護）。除了執(zhí)行其他作業(yè)外，CSS 還負責在集群內(nèi)節(jié)點間維持一個心跳的程序，并監(jiān)控投票磁盤的 split-brain 故障。在安裝 clusterware 的最后階段，會要求在每個節(jié)點執(zhí)行 root.sh 腳本，這個腳本會在/etc/inittab 文件的最后把這 3 個進程加入啟動項，這樣以后每次系統(tǒng)啟動時，clusterware 也會自動啟動，其中 EVMD 和 CRSD 兩個進程如果出現(xiàn)異常，則系統(tǒng)會自動重啟這兩個進程，如果是 CSSD 進程異常，系統(tǒng)會立即重啟。
注意：
1、Voting Disk 和 OCR 必須保存在存儲設(shè)備上供各個節(jié)點訪問。
2、Voting Disk、OCR 和網(wǎng)絡(luò)是安裝的過程中或者安裝前必須要指定或者配置的。安裝完成后可以通過一些工具進行配置和修改。
RAC 軟件結(jié)構(gòu)可以分為四部分。
(一) Operation System-Dependent（OSD）
RAC 通過操作系統(tǒng)的相關(guān)軟件來訪問操作系統(tǒng)和一些與 Cluster 相關(guān)的服務(wù)進程。OSD 軟件可能由 Oracle 提供（windows 平臺）或由硬件廠商提供（unix 平臺）。OSD 包括三個自部分：
(二) Real Application Cluster Shard Disk Component
RAC 中這部分組件和單實例 Oracle 數(shù)據(jù)庫中的組件沒有什么區(qū)別。包括一個或者多個控制文件、一些列聯(lián)機重做日志文件、可選的歸檔日志文件、數(shù)據(jù)文件等。在 RAC 中使用服務(wù)器參數(shù)文件會簡化參數(shù)文件的管理，可以將全局參數(shù)和實例特定的參數(shù)存儲在同一個文件中。
(三) Real Application Cluster-Specific Daemon and Instance Processes包括以下部分：
(四) The Global Cache and Global Enqueue Service
全局緩存服務(wù)（GCS）和全局隊列服務(wù)（GES）是 RAC 的集成組件，用于協(xié)調(diào)對共享數(shù)據(jù)庫和數(shù)據(jù)庫內(nèi)的共享資源的同時訪問。
GCS 和 GES 包括以下特性：
健忘問題是由于每個節(jié)點都有配置信息的拷貝，修改節(jié)點的配置信息不同步引起的。Oracle 采用的解決方法就是把這個配置文件放在共享的存儲上，這個文件就是 OCR Disk。OCR 中保存整個集群的配置信息，配置信息以”Key-Value” 的形式保存其中。在 Oracle 10g 以前，這個文件叫作 Server Manageability Repository(SRVM). 在 Oracle 10g，這部分內(nèi)容被重新設(shè)計，并重名為 OCR.在 Oracle Clusterware 安裝的過程中，安裝程序會提示用戶指定 OCR 位置。并且用戶指定的這個位置會被記錄在/etc/oracle/ocr.Loc(LinuxSystem) 或者/var/opt/oracle/ocr.Loc(SolarisSystem)文件中。而在 Oracle 9i RAC 中，對等的是 srvConfig.Loc 文件。Oracle Clusterware 在啟動時會根據(jù)這里面的內(nèi)容從指定位置讀入 OCR 內(nèi)容。
(一) OCR key
整個 OCR 的信息是樹形結(jié)構(gòu)，有 3 個大分支。分別是 SYSTEM,DATABASE 和 CRS。每個分支下面又有許多小分支。這些記錄的信息只能由 root 用戶修改。
(二) OCR process
Oracle Clusterware 在 OCR 中存放集群配置信息，故 OCR 的內(nèi)容非常的重要，所有對 OCR 的操作必須確保OCR 內(nèi)容完整性，所以在 ORACLE Clusterware 運行過程中，并不是所有結(jié)點都能操作 OCR Disk.在每個節(jié)點的內(nèi)存中都有一份 OCR 內(nèi)容的拷貝，這份拷貝叫作 OCR Cache。每個結(jié)點都有一個 OCR Process來讀寫 OCR Cache，但只有一個節(jié)點的 OCR process 能讀寫 OCR Disk 中的內(nèi)容，這個節(jié)點叫作 OCR Master 結(jié)點。這個節(jié)點的 OCR process 負責更新本地和其他結(jié)點的 OCR Cache 內(nèi)容。所有需要OCR 內(nèi)容的其他進程，比如OCSSD,EVM等都叫作Client Process，這些進程不會直接訪問OCR Cache，而是像 OCR Process發(fā)送請求，借助 OCR Process獲得內(nèi)容，如果想要修改 OCR 內(nèi)容，也要由該節(jié)點的 OCR Process像 Master node 的 OCR process 提交申請，由 Master OCR Process 完成物理讀寫，并同步所有節(jié)點 OCR Cache 中的內(nèi)容。
Voting Disk 這個文件主要用于記錄節(jié)點成員狀態(tài)，在出現(xiàn)腦裂時，決定那個 Partion 獲得控制權(quán)，其他的Partion 必須從集群中剔除。在安裝 Clusterware 時也會提示指定這個位置。安裝完成后可以通過如下命令來查看Voting Disk 位置。$Crsctl query css votedisk
一、專用網(wǎng)絡(luò)
每個集群節(jié)點通過專用高速網(wǎng)絡(luò)連接到所有其他節(jié)點，這種專用高速網(wǎng)絡(luò)也稱為集群互聯(lián)或高速互聯(lián) (HSI)。Oracle 的 Cache Fusion 技術(shù)使用這種網(wǎng)絡(luò)將每個主機的物理內(nèi)存 (RAM) 有效地組合成一個高速緩存。 OracleCache Fusion 通過在專用網(wǎng)絡(luò)上傳輸某個 Oracle 實例高速緩存中存儲的數(shù)據(jù)允許其他任何實例訪問這些數(shù)據(jù)。它還通過在集群節(jié)點中傳輸鎖定和其他同步信息保持數(shù)據(jù)完整性和高速緩存一致性。專用網(wǎng)絡(luò)通常是用千兆以太網(wǎng)構(gòu)建的，但是對于高容量的環(huán)境，很多廠商提供了專門為 Oracle RAC 設(shè)計的低延遲、高帶寬的專有解決方案。 Linux 還提供一種將多個物理 NIC 綁定為一個虛擬 NIC 的方法（此處不涉及）來增加帶寬和提高可用性。
二、公共網(wǎng)絡(luò)
為維持高可用性，為每個集群節(jié)點分配了一個虛擬 IP 地址 (VIP)。 如果主機發(fā)生故障，則可以將故障節(jié)點的 IP 地址重新分配給一個可用節(jié)點，從而允許應(yīng)用程序通過相同的 IP 地址繼續(xù)訪問數(shù)據(jù)庫。
三、Virtual lP（VIP）
即虛擬 IP，Oracle 推薦客戶端連接時通過指定的虛擬 IP 連接，這也是 Oracle10g 新推出的一個特性。其本質(zhì)目的是為了實現(xiàn)應(yīng)用的無停頓(雖然目前還是有點小問題，但離目標已經(jīng)非常接近)。用戶連接虛 IP，這個 IP并非綁定于網(wǎng)卡，而是由 oracle 進程管理，一旦某個用戶連接的虛 IP 所在實例宕機，oracle 會自動將該 IP 映射到狀態(tài)正常的實例，這樣就不會影響到用戶對數(shù)據(jù)庫的訪問，也無須用戶修改應(yīng)用。Oracle 的 TAF 建立在 VIP 技術(shù)之上。IP 和 VIP 區(qū)別在與： IP 是利用 TCP 層超時， VIP 利用的是應(yīng)用層的立即響應(yīng)。VIP 它是浮動的 IP. 當一個節(jié)點出現(xiàn)問題時會自動的轉(zhuǎn)到另一個節(jié)點上。
透明應(yīng)用故障轉(zhuǎn)移（Transport Application Failover，TAF）是 oracle 數(shù)據(jù)提供的一項，普遍應(yīng)用于 RAC 環(huán)境中，當然也可以用于 Data Guard 和傳統(tǒng)的 HA 實現(xiàn)的主從熱備的環(huán)境中。TAF 中的 Transparent 和 Failover，點出了這個高可用特性的兩大特點：
但是，TAF 是完美的嗎？是不是使用了 TAF，應(yīng)用就能真的無縫地進行切換呢？對應(yīng)用和數(shù)據(jù)庫有沒有其他什么要求？要回答這些問題，我們需要全面地了解、掌握 TAF。我始終認為，要用好一個東西，首先得掌握這個東西背后的工作原理與機制。首先來看看 Failover。Failover 有兩種，一種是連接時 Failover，另一種則是運行時 Failover。前者的作用在于，應(yīng)用（客戶端）在連接數(shù)據(jù)庫時，如果由于網(wǎng)絡(luò)、實例故障等原因，連接不上時，能夠連接數(shù)據(jù)庫中的其他實例。后者的作用在于，對于一個已經(jīng)在工作的會話（也就是連接已經(jīng)建立），如果這個會話的實例異常中止等，應(yīng)用（客戶端）能夠連接到數(shù)據(jù)庫的其他實例（或備用庫）。
負載均衡（Load-Banlance）是指連接的負載均衡。RAC 的負載均衡主要指的是新會話連接到 RAC 數(shù)據(jù)庫時，根據(jù)服務(wù)器節(jié)點的 CPU 負載判定這個新的連接要連接到哪個節(jié)點進行工作。Oracle RAC 可以提供動態(tài)的數(shù)據(jù)服務(wù)，負載均衡分為兩種，一種是基于客戶端連接的，一種是基于服務(wù)器端的。
Oracle 的 TAF 建立在 VIP 的技術(shù)之上。IP 和 VIP 區(qū)別在于：IP 是利用 TCP 層超時，VIP 利用的是應(yīng)用層的立即響應(yīng)。VIP 是是浮動的 IP，當一個節(jié)點出現(xiàn)問題的時候，會自動的轉(zhuǎn)到另一個節(jié)點上。假設(shè)有一個兩節(jié)點的 RAC，正常運行時每個節(jié)點上都有一個 VIP，即 VIP1 和 VIP2。當節(jié)點 2 發(fā)生故障，比如異常關(guān)系。RAC 會做如下操作：
(一) CRS 在檢測到 rac2 節(jié)點異常后，會觸發(fā) Clusterware 重構(gòu)，最后把 rac2 節(jié)點剔除集群，由節(jié)點 1 組成新的集群。
(二) RAC 的 Failover 機制會把節(jié)點 2 的 VIP 轉(zhuǎn)移到節(jié)點 1 上，這時節(jié)點 1 的 PUBLIC 網(wǎng)卡上就有 3 個 IP 地址：VIP1,VIP2, PUBLIC IP1.
(三) 用戶對 VIP2 的連接請求會被 IP 層路由轉(zhuǎn)到節(jié)點 1
(四) 因為在節(jié)點 1 上有 VIP2 的地址，所有數(shù)據(jù)包會順利通過路由層，網(wǎng)絡(luò)層，傳輸層。
(五) 但是，節(jié)點 1 上只監(jiān)聽 VIP1 和 public IP1 的兩個 IP 地址。并沒有監(jiān)聽 VIP2，故應(yīng)用層沒有對應(yīng)的程序接收這個數(shù)據(jù)包，這個錯誤立即被捕獲。
(六) 客戶端能夠立即接收到這個錯誤，然后客戶端會重新發(fā)起向 VIP1 的連接請求。VIP 特點：
Redo Thread
RAC 環(huán)境下有多個實例，每個實例都需要有自己的一套 Redo Log 文件來記錄日志。這套 Redo Log 就叫做 RedoThread，其實單實例下也是 Redo Thread，只是這個詞很少被提及，每個實例一套 Redo Thread 的設(shè)計就是為了避免資源競爭造成的性能瓶頸。Redo Thread 有兩種，一種是 Private，創(chuàng)建語法 alter database add logfile ......thread n；另一種是 public，創(chuàng)建語法：alter database add logfile......；RAC 中每個實例都要設(shè)置 thread 參數(shù)，該參數(shù)默認值為 0。如果設(shè)置了這個參數(shù)，則使用缺省值 0，啟動實例后選擇使用 Public Redo Thread，并且實例會用獨占的方式使用該 Redo Thread。RAC 中每個實例都需要一個 Redo Thread，每個 Redo Log Thread 至少需要兩個 Redo Log Group，每個 Log Group成員大小應(yīng)該相等，沒組最好有 2 個以上成員，這些成員應(yīng)放在不同的磁盤上，防止單點故障。
注意：在 RAC 環(huán)境下，Redo Log Group 是在整個數(shù)據(jù)庫級別進行編號，如果實例 1 有 1,2 兩個日志組，那么實例 2 的日志組編號就應(yīng)該從 3 開始，不能使用 1,2 編號了。在 RAC 環(huán)境上，所有實例的聯(lián)機日志必須放在共享存儲上，因為如果某個節(jié)點異常關(guān)閉，剩下的節(jié)點要進行 crash recovery，執(zhí)行 crash recovery 的這個節(jié)點必須能夠訪問到故障節(jié)點的連接日志，只有把聯(lián)機日志放在共享存儲上才能滿足這個要求。
Archive log
RAC 中的每個實例都會產(chǎn)生自己的歸檔日志，歸檔日志只有在執(zhí)行 Media Recovery 時才會用到，所以歸檔日志不必放在共享存儲上，每個實例可以在本地存放歸檔日志。但是如果在單個實例上進行備份歸檔日志或者進行 Media Recovery 操作，又要求在這個節(jié)點必須能夠訪問到所有實例的歸檔日志，在 RAC 幻境下，配置歸檔日志可以有多種選擇。
使用 NFS 的方式將日志直接歸檔到存儲，例如兩個節(jié)點，每個節(jié)點都有 2 個目錄，Arch2，Arch3 分別對應(yīng)實例 1 和實例 2 產(chǎn)生的歸檔日志。每個實例都配置一個歸檔位置，歸檔到本地，然后通過 NFS 把對方的目錄掛到本地。
實例間歸檔（Cross Instance Archive）是上一種方式的變種，也是比較常見的一種配置方法。兩個節(jié)點都創(chuàng)建 2 個目錄 Arch2 和 Arch3 分別對應(yīng)實例 1 和實例 2 產(chǎn)生的歸檔日志。每個實例都配置兩個歸檔位置。位置 1對應(yīng)本地歸檔目錄，位置 2 對應(yīng)另一個實例
使用 ASM 將日志歸檔到共享存儲，只是通過 Oracle 提供的 ASM，把上面的復(fù)雜性隱藏了，但是原理都一樣。
Trace 日志
Oracle Clusterware 的輔助診斷，只能從 log 和 trace 進行。 而且它的日志體系比較復(fù)雜。 alert.log：$ORA_CRS_HOME/log/hostname/alert.Log, 這是首選的查看文件。
Clusterware 后臺進程日志
Nodeapp 日志位置
ORACRSHOME/log/hostname/racg/這里面放的是nodeapp的日志，包括ONS和VIP，比如：ora.Rac1.ons.Log工具執(zhí)行日志：ORACRSHOME/log/hostname/racg/這里面放的是nodeapp的日志，包括ONS和VIP，比如：ora.Rac1.ons.Log工具執(zhí)行日志：ORA_CRS_HOME/log/hostname/client/
Clusterware 提供了許多命令行工具 比如 ocrcheck, ocrconfig,ocrdump,oifcfg 和 clscfg, 這些工具產(chǎn)生的日志就放在這個目錄下，還有ORACLEHOME/log/hostname/client/和ORACLEHOME/log/hostname/client/和ORACLE_HOME/log/hostname/racg 也有相關(guān)的日志。
前面已經(jīng)介紹了 RAC 的后臺進程，為了更深入的了解這些后臺進程的工作原理，先了解一下 RAC 中多節(jié)點對共享數(shù)據(jù)文件訪問的管理是如何進行的。要了解 RAC 工作原理的中心，需要知道 Cache Fusion 這個重要的概念，要發(fā)揮 Cache Fusion 的作用，要有一個前提條件，那就是互聯(lián)網(wǎng)絡(luò)的速度要比訪問磁盤的速度要快。否則，沒有引入 Cache Fusion 的意義。而事實上，現(xiàn)在 100MB 的互聯(lián)網(wǎng)都很常見。
Cache Fusion 就是通過互聯(lián)網(wǎng)絡(luò)（高速的 Private interconnect）在集群內(nèi)各節(jié)點的 SGA 之間進行塊傳遞，這是RAC最核心的工作機制，他把所有實例的SGA虛擬成一個大的SGA區(qū)，每當不同的實例請求相同的數(shù)據(jù)塊時，這個數(shù)據(jù)塊就通過 Private interconnect 在實例間進行傳遞。以避免首先將塊推送到磁盤，然后再重新讀入其他實例的緩存中這樣一種低效的實現(xiàn)方式(OPS 的實現(xiàn))。當一個塊被讀入 RAC 環(huán)境中某個實例的緩存時，該塊會被賦予一個鎖資源（與行級鎖不同），以確保其他實例知道該塊正在被使用。之后，如果另一個實例請求該塊的一個副本，而該塊已經(jīng)處于前一個實例的緩存內(nèi)，那么該塊會通過互聯(lián)網(wǎng)絡(luò)直接被傳遞到另一個實例的 SGA。如果內(nèi)存中的塊已經(jīng)被改變，但改變尚未提交，那么將會傳遞一個 CR 副本。這就意味著只要可能，數(shù)據(jù)塊無需寫回磁盤即可在各實例的緩存之間移動，從而避免了同步多實例的緩存所花費的額外 I/O。很明顯，不同的實例緩存的數(shù)據(jù)可以是不同的，也就是在一個實例要訪問特定塊之前，而它又從未訪問過這個塊，那么它要么從其他實例 cache fusion 過來，或者從磁盤中讀入。GCS（Global Cache Service，全局內(nèi)存服務(wù)）和 GES（Global EnquenceService，全局隊列服務(wù)）進程管理使用集群節(jié)點之間的數(shù)據(jù)塊同步互聯(lián)。
這里還是有一些問題需要思考的：
鎖是在各實例的 SGA 中保留的資源，通常被用于控制對數(shù)據(jù)庫塊的訪問。每個實例通常會保留或控制一定數(shù)量與塊范圍相關(guān)的鎖。當一個實例請求一個塊時，該塊必須獲得一個鎖，并且鎖必須來自當前控制這些鎖的實例。也就是鎖被分布在不同的實例上。而要獲得特定的鎖要從不同的實例上去獲得。但是從這個過程來看這些鎖不是固定在某個實例上的，而是根據(jù)鎖的請求頻率會被調(diào)整到使用最頻繁的實例上，從而提高效率。要實現(xiàn)這些資源的分配和重分配、控制，這是很耗用資源的。這也決定了 RAC 的應(yīng)用設(shè)計要求比較高。假設(shè)某個實例崩潰或者某個實例加入，那么這里要有一個比較長的再分配資源和處理過程。在都正常運行的情況下會重新分配，以更加有效的使用資源；在實例推出或加入時也會重新分配。在 alert 文件中可以看到這些信息。而 Cache Fusion 及其他資源的分配控制，要求有一個快速的互聯(lián)網(wǎng)絡(luò)，所以要關(guān)注與互聯(lián)網(wǎng)絡(luò)上消息相關(guān)的度量，以測試互聯(lián)網(wǎng)絡(luò)的通信量和相應(yīng)時間。對于前面的一些問題，可以結(jié)合另外的概念來學習，它們是全局緩存服務(wù)和全局隊列服務(wù)。
全局緩存服務(wù)(GCS):要和 Cache Fusion 結(jié)合在一起來理解。全局緩存要涉及到數(shù)據(jù)塊。全局緩存服務(wù)負責維護該全局緩沖存儲區(qū)內(nèi)的緩存一致性，確保一個實例在任何時刻想修改一個數(shù)據(jù)塊時，都可獲得一個全局鎖資源，從而避免另一個實例同時修改該塊的可能性。進行修改的實例將擁有塊的當前版本（包括已提交的和未提交的事物）以及塊的前象(post image)。如果另一個實例也請求該塊，那么全局緩存服務(wù)要負責跟蹤擁有該塊的實例、擁有塊的版本是什么，以及塊處于何種模式。LMS 進程是全局緩存服務(wù)的關(guān)鍵組成部分。
猜想：Oracle 目前的 cache fusion 是在其他實例訪問時會將塊傳輸過去再構(gòu)建一個塊在那個實例的 SGA 中，這個主要的原因可能是 interconnect 之間的訪問還是從本地內(nèi)存中訪問更快，從而讓 Oracle 再次訪問時可以從本地內(nèi)存快速獲取。但是這也有麻煩的地方，因為在多個節(jié)點中會有數(shù)據(jù)塊的多個 copy，這樣在管理上的消耗是很可觀的，Oracle 是否會有更好的解決方案出現(xiàn)在后續(xù)版本中？如果 interconnect 速度允許的話...）
全局隊列服務(wù)(GES)：主要負責維護字典緩存和庫緩存內(nèi)的一致性。字典緩存是實例的 SGA 內(nèi)所存儲的對數(shù)據(jù)字典信息的緩存，用于高速訪問。由于該字典信息存儲在內(nèi)存中，因而在某個節(jié)點上對字典進行的修改（如DDL)必須立即被傳播至所有節(jié)點上的字典緩存。GES 負責處理上述情況，并消除實例間出現(xiàn)的差異。處于同樣的原因，為了分析影響這些對象的 SQL 語句，數(shù)據(jù)庫內(nèi)對象上的庫緩存鎖會被去掉。這些鎖必須在實例間進行維護，而全局隊列服務(wù)必須確保請求訪問相同對象的多個實例間不會出現(xiàn)死鎖。LMON、LCK 和 LMD 進程聯(lián)合工作來實現(xiàn)全局隊列服務(wù)的功能。GES 是除了數(shù)據(jù)塊本身的維護和管理（由 GCS 完成）之外，在 RAC 環(huán)境中調(diào)節(jié)節(jié)點間其他資源的重要服務(wù)。
SQL> select * from gv$sysstat where name like 'gcs %'
這里可以看到 gcs 和 ges 消息的發(fā)送個數(shù)。（如果沒有使用 DBCA 來創(chuàng)建數(shù)據(jù)庫，那么要 SYSDBA 權(quán)限來運行CATCLUST.SQL 腳本來創(chuàng)建 RAC 相關(guān)的視圖和表）
Oracle failsafe、Data Guard 和 RAC 均為 ORACLE 公司提供的高可靠性（HA）解決方案。然而之三者之間卻存在著很大區(qū)別。HA 是 High Availability 的首字母組合，翻譯過來，可以叫做高可用，或高可用性，高可用（環(huán)境）。我覺得應(yīng)該說 HA 是一個觀念而不是一項或一系列具體技術(shù)，就象網(wǎng)格一樣。作過系統(tǒng)方案就知道了，評價系統(tǒng)的性能當中就有一項高可用。也就是 OS 一級的雙機熱備。RAC 是 real application cluster 的簡稱，它是在多個主機上運行一個數(shù)據(jù)庫的技術(shù)，即是一個 db 多個 instance。它的好處是 可以由多個性能較差的機器構(gòu)建出一個整體性能很好的集群，并且實現(xiàn)了負載均衡，那么當一個節(jié)點出現(xiàn)故障時，其上的服務(wù)會自動轉(zhuǎn)到另外的節(jié)點去執(zhí)行，用戶甚 至感覺不到什么。
1、 操作系統(tǒng)：
failsafe 系統(tǒng)局限于 WINDOWS 平臺，必須配合 MSCS（microsoft cluster server），而 RAC 最早是在 UNIX 平臺推出的，目前已擴展至 LINUX 和 WINDOWS 平臺，通過 OSD（operating system dependent）與系統(tǒng)交互。對于高端的 RAC 應(yīng)用，UNIX 依然是首選的平臺。
2、 系統(tǒng)結(jié)構(gòu)：
FAILSAFE 采用的是 SHARE NOTHING 結(jié)構(gòu)，即采用若干臺服務(wù)器組成集群，共同連接到一個共享磁盤系統(tǒng)，在同一時刻，只有一臺服務(wù)器能夠訪問共享磁盤，能夠?qū)ν馓峁┓?wù)。只要當此服務(wù)器失效時，才有另一臺接管共享磁盤。RAC 則是采用 SHARE EVERYTHING，組成集群的每一臺服務(wù)器都可以訪問共享磁盤，都能對外提供服務(wù)。也就是說 FAILSAFE 只能利用一臺服務(wù)器資源，RAC 可以并行利用多臺服務(wù)器資源。
3、 運行機理：
組成 FAILSAFE 集群的每臺 SERVER 有獨立的 IP，整個集群又有一個 IP，另外還為 FAILSAFE GROUP 分配一個單獨的 IP（后兩個 IP 為虛擬 IP，對于客戶來說，只需知道集群 IP，就可以透明訪問數(shù)據(jù)庫）。工作期間，只有一臺服務(wù)器（preferred or owner or manager）對外提供服務(wù)，其余服務(wù)器(operator)成待命狀，當前者失效時，另一服務(wù)器就會接管前者，包括FAILSAFE GROUP IP與CLUSTER IP，同時FAILSAFE會啟動上面的DATABASE SERVICE，LISTENER 和其他服務(wù)?？蛻糁灰匦逻B接即可，不需要做任何改動。對于 RAC 組成的集群，每臺服務(wù)器都分別有自已的 IP，INSTANCE 等，可以單獨對外提供服務(wù)，只不過它們都是操作位于共享磁盤上的同一個數(shù)據(jù)庫。當某臺服務(wù)器失效后，用戶只要修改網(wǎng)絡(luò)配置，如（TNSNAMES。ORA），即可重新連接到仍在正常運行的服務(wù)器上。但和 TAF 結(jié)合使用時，甚至網(wǎng)絡(luò)也可配置成透明的。
4、 集群容量：
前者通常為兩臺，后者在一些平臺上能擴展至 8 臺。
5、 分區(qū)：
FAILSAFE 數(shù)據(jù)庫所在的磁盤必須是 NTFS 格式的，RAC 則相對靈活，通常要求是 RAW，然而若干 OS 已操作出了 CLUSTER 文件系統(tǒng)可以供 RAC 直接使用。綜上所述，F(xiàn)AILSAFE 比較適合一個可靠性要求很高，應(yīng)用相對較小，對高性能要求相對不高的系統(tǒng)，而 RAC則更適合可靠性、擴展性、性能要求都相對較高的較大型的應(yīng)用。
RAC 是 OPS 的后繼版本，繼承了 OPS 的概念，但是 RAC 是全新的，CACHE 機制和 OPS 完全不同。RAC 解決了 OPS 中 2 個節(jié)點同時寫同一個 BLOCK 引起的沖突問題。 從產(chǎn)品上來說 RAC 和 OPS 是完全不同的產(chǎn)品，但是我們可以認為是相同產(chǎn)品的不同版本
Data Guard 是 Oracle 的遠程復(fù)制技術(shù)，它有物理和邏輯之分，但是總的來說，它需要在異地有一套獨立的系統(tǒng)，這是兩套硬件配置可以不同的系統(tǒng)，但是這兩套系統(tǒng)的軟件結(jié)構(gòu)保持一致，包括軟件的版本，目錄存儲結(jié)構(gòu)，以及數(shù)據(jù)的同步（其實也不是實時同步的），這兩套系統(tǒng)之間只要網(wǎng)絡(luò)是通的就可以了，是一種異地容災(zāi)的解決方案。而對于 RAC，則是本地的高可用集群，每個節(jié)點用來分擔不用或相同的應(yīng)用，以解決運算效率低下，單節(jié)點故障這樣的問題，它是幾臺硬件相同或不相同的服務(wù)器，加一個 SAN（共享的存儲區(qū)域）來構(gòu)成的。Oracle 高可用性產(chǎn)品比較見下表：
通常在 RAC 環(huán)境下，在公用網(wǎng)絡(luò)的基礎(chǔ)上，需要配置兩條專用的網(wǎng)絡(luò)用于節(jié)點間的互聯(lián)，在 HACMP/ES 資源的定義中，這兩條專用的網(wǎng)絡(luò)應(yīng)該被定義為"private" 。在實例啟動的過程中，RAC 會自動識別和使用這兩條專用的網(wǎng)絡(luò)，并且如果存在公用"public" 的網(wǎng)絡(luò)，RAC 會再識別一條公用網(wǎng)絡(luò)。當 RAC 識別到多條網(wǎng)絡(luò)時，RAC會使用 TNFF (Transparent Network Failvoer Failback) 功能，在 TNFF 下所有的節(jié)點間通信都通過第一條專用的網(wǎng)絡(luò)進行，第二條( 或第三條等) 作為在第一條專用的網(wǎng)絡(luò)失效后的備份。RAC 節(jié)點間通信如下圖所示。
CLUSTER_INTERCONNECTS 是在 Oracle RAC 中的一個可選的初始化(init.ora) 參數(shù)。此參數(shù)可以指定使用哪一條網(wǎng)絡(luò)用于節(jié)點間互聯(lián)通信，如果指定多條網(wǎng)絡(luò)，RAC 會在這些網(wǎng)絡(luò)上自動進行負載均衡。然而，當CLUSTER_INTERCONNECTS 設(shè)置時，TNFF 不起作用，這將降低 RAC 的可用性，任何一條節(jié)點間互聯(lián)網(wǎng)絡(luò)的失效，都會造成 RAC 一個或多個節(jié)點的失效。ORACLE RAC 用于 INTERCONNECT 的內(nèi)網(wǎng)卡的物理連接方式的選擇：采用交換機連接或是網(wǎng)線直連。直連的弊端是，一旦一個節(jié)點機的內(nèi)網(wǎng)卡出現(xiàn)故障，oracle 從 OS 得到兩個節(jié)點的網(wǎng)卡狀態(tài)都是不正常的，因而會導(dǎo)致兩個實例都宕掉。在 INTERCONNECT 線路出現(xiàn)問題的時候，oracle 一般情況下會啟動一個競爭機制來決定哪個實例宕掉，如果宕掉的實例正好是好的實例的話， 這樣就會導(dǎo)致兩個實例都宕掉。在 9i 中，oracle 在啟動競爭機制之前，會先等待一段時間，等待 OS 將網(wǎng)絡(luò)的狀態(tài)發(fā)給 oracle，如果在超時之前，oracle 獲得哪個實例的網(wǎng)卡是 down 的話，則將該實例宕掉，這樣的話，則可以保留正常的那個實例繼續(xù)服務(wù)，否則還是進入競爭機制。
綜上所述節(jié)點間通信分為兩種情況：
? 是接在交換機上面，此時一般情況下，是會保證正常的實例繼續(xù)服務(wù)的，但有的時候如果 os 來不及將網(wǎng)卡狀態(tài)送到 oracle 時，也是有可能會導(dǎo)致兩個節(jié)點都宕掉的。
? 如果是直連的話，則會導(dǎo)致兩個實例都宕掉。
CSS 心跳
OCSSD 這個進程是 Clusterware 最關(guān)鍵的進程，如果這個進程出現(xiàn)異常，會導(dǎo)致系統(tǒng)重啟，這個進程提供CSS(Cluster Synchronization Service)服務(wù)。 CSS 服務(wù)通過多種心跳機制實時監(jiān)控集群狀態(tài)，提供腦裂保護等基礎(chǔ)集群服務(wù)功能。
CSS 服務(wù)有 2 種心跳機制： 一種是通過私有網(wǎng)絡(luò)的 Network Heartbeat，另一種是通過 Voting Disk 的 DiskHeartbeat。這 2 種心跳都有最大延時，對于 Disk Heartbeat，這個延時叫作 IOT (I/O Timeout);對于 Network Heartbeat, 這個延時叫 MC(Misscount)。這 2 個參數(shù)都以秒為單位，缺省時 IOT 大于 MC，在默認情況下，這 2 個參數(shù)是 Oracle自動判定的，并且不建議調(diào)整?？梢酝ㄟ^如下命令來查看參數(shù)值：
$crsctl get css disktimeout
$crsctl get css misscount
Oracle RAC 節(jié)點間使用的通信協(xié)議見下表。
LOCK（鎖）是用來控制并發(fā)的數(shù)據(jù)結(jié)構(gòu)，如果有兩個進程同時修改同一個數(shù)據(jù)， 為了防止出現(xiàn)混亂和意外，用鎖來控制訪問數(shù)據(jù)的次序。有鎖的可以先訪問，另外一個進程要等到第一個釋放了鎖，才能擁有鎖，繼續(xù)訪問?？傮w來說,RAC 里面的鎖分兩種， 一種是本地主機的進程之間的鎖，另外一種是不同主機的進程之間的鎖。本地鎖的機制有兩類，一類叫做 lock（鎖），另外一類叫做 latch 閂。
全局鎖就是指 RAC lock，就是不同主機之間的鎖，Oracle 采用了 DLM（Distributed Lock Management，分布式鎖管理）機制。在 Oracle RAC 里面，數(shù)據(jù)是全局共享的，就是說每個進程看到的數(shù)據(jù)塊都是一樣的，在不同機器間，數(shù)據(jù)塊可以傳遞。給出了 GRD目錄結(jié)構(gòu)。
可以看出 Mode、Role、n 構(gòu)成了 RAC lock 的基本結(jié)構(gòu)
數(shù)據(jù)一致性和并發(fā)性描述了 Oracle 如何維護多用戶數(shù)據(jù)庫環(huán)境中的數(shù)據(jù)一致性問題。在單用戶數(shù)據(jù)庫中，用戶修改數(shù)據(jù)庫中的數(shù)據(jù)，不用擔心其他用戶同時修改相同的數(shù)據(jù)。但是，在多用戶數(shù)據(jù)庫中，同時執(zhí)行的多個事務(wù)中的語句可以修改同一數(shù)據(jù)。同時執(zhí)行的事務(wù)需要產(chǎn)生有意義的和一致性的結(jié)果。因而，在多用戶數(shù)據(jù)庫中，數(shù)據(jù)并發(fā)性和數(shù)據(jù)一致性的控制非常重要：數(shù)據(jù)并發(fā)性：每個用戶可以看到數(shù)據(jù)的一致性結(jié)果。ANSI/IOS SQL 標準（SQL 92）定義了 4 個事務(wù)隔離級別，對事務(wù)處理性能的影響也個不相同。這些隔離級別是考慮了事務(wù)并發(fā)執(zhí)行必須避免的 3 個現(xiàn)象提出的。3 個應(yīng)該避免的現(xiàn)象為： ? ?
SQL92 根據(jù)這些對象定義了 4 個隔離級別，事務(wù)運行在特定的隔離級別允許特別的一些表現(xiàn)。如下表表示隔離級別阻止的讀現(xiàn)象。
(一) OCR KEY 是樹形結(jié)構(gòu)。
(二) OCR PROCESS 每個節(jié)點都有 OCR CACHE 的復(fù)制，由 ORC MASTER 節(jié)點負責更新到 OCR DISK
自動啟動的腳本/etc/inittab 里定義：
OCSSD（Clustery Synchronization Service）提供心跳機制監(jiān)控集群狀態(tài)
DISK HEARTBEAT
NETWORK HEARBEAT
CRSD（Clustery Ready Service）提供高可用、干預(yù)、關(guān)閉、重啟、轉(zhuǎn)移服務(wù)。
資源包括 nodeapps、database-related：前者每個節(jié)點只需要一個即可正常工作，后一個與數(shù)據(jù)庫相關(guān)，不受節(jié)點限制，可以為多個。
EVMD： 這個進程負責發(fā)布 CRS 產(chǎn)生的各種事件，還是 CRS 和 CSS 兩個服務(wù)之間通信的橋梁
RACGIMON： 這個進程負責檢查數(shù)據(jù)庫健康狀態(tài)，包括數(shù)據(jù)庫服務(wù)的啟動、停止和故障轉(zhuǎn)移。屬于持久連接，定期檢查 SGA。
OPROCD（Process Monitor Daemon）檢測 CPU hang（非 Linux 平臺使用）
DLM 分布式鎖管理。
(一) NM（NODE MANAGEMENT）group
(二) 重構(gòu)集群觸發(fā)：有 node 加入或者離開集群，由 NM 觸發(fā) Network Heartbeat 異常：因為 LMON 或者 GCS、GES 通信異常 ，由 IMR（Instance Membership Reconfiguration）controlfile heartbeat 觸發(fā)。
(一) 多節(jié)點負載均衡
(二) 提供高可用性，故障容錯及無縫切換功能，將硬件和軟件的異常造成的影響最小化。
(三) 通過并行執(zhí)行技術(shù)提供事務(wù)響應(yīng)的時間 - 通常用于數(shù)據(jù)分析系統(tǒng)。
(四) 通過橫向擴展提高每秒交易數(shù)和連接數(shù) - 通常用于 OLTP。
(五) 節(jié)約硬件成本，可以使用多個廉價的 PC 服務(wù)器代替小型機大型機，節(jié)約相應(yīng)的維護成本。
(六) 可擴展性好，可以方便添加刪除節(jié)點，擴展硬件資源。
(一) 管理更復(fù)雜，要求更高
(二) 系統(tǒng)規(guī)劃設(shè)計較差時性能可能會不如單節(jié)點
(三) 可能會增加軟件成本(按照 CPU 收費)
在需要將一個 LUN （邏輯單元號）映射給多個節(jié)點、為集群提供一個共享的存儲卷時，同一個存儲 LUN 在各個主機端的 LUNID 必須是相同的。比如：
(一) 在為多個 ESX 節(jié)點創(chuàng)建一個 VMFS 卷的時候
(二) 在雙機 HA 集群創(chuàng)建共享存儲的時候
集群模式下，各個節(jié)點要協(xié)同工作，因此，各主機的時間必須一致。因此，各主機的時間必須一致。各個節(jié)點之間的時間差不能超時，一般如果超過 30s，節(jié)點很可能會重啟，所以要同步各節(jié)點的時間。例如，需要配置一個 ntp 時鐘服務(wù)器，來給 RAC 的各個節(jié)點進行時間同步。或者讓節(jié)點之間進行時間同步，保證各個節(jié)點的時間同步，但是無法保證 RAC 數(shù)據(jù)庫的時間的準確性。
集群必須依賴內(nèi)部的互聯(lián)網(wǎng)絡(luò)實現(xiàn)數(shù)據(jù)通訊或者心跳功能。因此，采用普通的以太網(wǎng)還是其他的高速網(wǎng)絡(luò)(比如 IB)，就很有講究，當然了，還有拿串口線實現(xiàn)心跳信息傳遞。此外，采用什么樣的網(wǎng)絡(luò)參數(shù)對集群整體的性能和健壯性都大有關(guān)系。
案例：
XX 市，4 節(jié)點 Oracle 10g RAC
操作系統(tǒng)采用的是 RHEL 4，按照默認的安裝文檔，設(shè)置網(wǎng)絡(luò)參數(shù)為如下值：
net.core.rmem_default = 262144
net.core.rmem_max = 262144
執(zhí)行一個查詢語句，需要 11 分鐘，修改參數(shù)：
net.core.rmem_default = 1048576
net.core.rmem_max = 1048576
再次執(zhí)行僅需 16.2 秒。
案例：
XX 市，HPC 集群，運行 LS-DYNA(通用顯示非線性有限元分析程序)。
集群存儲系統(tǒng)的環(huán)境說明：存儲系統(tǒng)的 3 個 I/O 節(jié)點通過 FC SAN 交換機連接到一個共享的存儲。
故障現(xiàn)象
集群到貨后發(fā)現(xiàn)盤陣與機器直連能通，兩個設(shè)備接 200E 交換機不通。后經(jīng)測試交換機 IOS 版本問題導(dǎo)致不能正常認出盤陣的光纖端口，與交換機的供貨商聯(lián)系更新了兩次 IOS，盤陣的端口能正常識別，但盤陣與機器相連還是無法找到盤陣。經(jīng)過今天的測試發(fā)現(xiàn)三臺 I/O 節(jié)點采用的 HBA 卡 firmware 版本不一致。最早接光纖交換機及與盤陣直連的的 I/O1 的 firmware 為 v4.03.02，今天又拿出來的兩臺 I/O 節(jié)點 firmware 為 v4.06.03。用后兩臺測試后盤陣、機器、交換機之間可以正常通信，到今天晚上為止沒有發(fā)現(xiàn)異常情況。從目前的情況判斷是QLE2460 firmware 為 v4.03.01 的 HBA 卡與 200E IOS V5.3.1 有沖突者不兼容導(dǎo)致的故障。至于新的 HBA 卡 firmware為 v4.06.03 與 200E IOS V5.3.1 連接的穩(wěn)定性如何還要做進一步測試。
診斷處理結(jié)果
I/O 1 節(jié)點 HBA 卡的 fimware 升級到 v4.06.03 后連接 200E 找不到盤陣的故障已經(jīng)得到解決。其實是一個 FCHBA 卡的固件版本不一致引起的問題。
Oracle Cluster Registry（OCR）：記錄 OCR 記錄節(jié)點成員的配置信息，如 database、ASM、instance、 listener、VIP 等 CRS 資源的配置信息,可存儲于裸設(shè)備或者群集文件系統(tǒng)上。Voting disk : 即仲裁盤，保存節(jié)點的成員信息，當配置多個投票盤的時候個數(shù)必須為奇數(shù)，每個節(jié)點必須同時能夠連接半數(shù)以上的投票盤才能夠存活。初次之外包含哪些節(jié)點成員、節(jié)點的添加和刪除信息。
在 Oracle RAC 中，軟件不建議安裝在共享文件系統(tǒng)上，包括 CRS_HOME 和 ORACLE_HOME，尤其是 CRS 軟件，推薦安裝在本地文件系統(tǒng)中，這樣在進行軟件升級，以及安裝 patch 和 patchset 的時候可以使用滾動升級(rolling upgrade)的方式，減少計劃當機時間。另外如果軟件安裝在共享文件系統(tǒng)也會增加單一故障點。如果使用 ASM 存儲，需要為 asm 單獨安裝 ORACLE 軟件，獨立的 ORACLE_HOME，易于管理和維護，比如當遇到 asm 的 bug 需要安裝補丁時，就不會影響 RDBMS 文件和軟件。
在一個共享存儲的集群中，當集群中 heartbeat 丟失時，如果各節(jié)點還是同時對共享存儲去進行操作，那么在這種情況下所引發(fā)的情況是災(zāi)難的。ORACLE RAC 采用投票算法來解決這個問題，思想是這樣的：每個節(jié)點都有一票，考慮有 A，B，C 三個節(jié)點的集群情形，當 A 節(jié)點由于各種原因不能與 B，C 節(jié)點通信時，那么這集群分成了兩個 DOMAIN,A 節(jié)點成為一個 DOMAIN，擁有一票；B,C 節(jié)點成為一個 DOMAIN 擁有兩票，那么這種情況B，C 節(jié)點擁有對集群的控制權(quán)，從而把 A 節(jié)點踢出集群，對要是通 IO FENCING 來實現(xiàn)。如果是兩節(jié)點集群，則引入了仲裁磁盤，當兩個節(jié)點不能通信時，請求最先到達仲裁磁盤的節(jié)點擁用對集群的控制權(quán)。網(wǎng)絡(luò)問題（interconnect 斷了），時間不一致；misscount 超時 等等，才發(fā)生 brain split，而此時為保護整個集群不受有問題的節(jié)點影響，而發(fā)生 brain split。oracle 采用的是 server fencing，就是重啟有問題的節(jié)點，試圖修復(fù)問題。當然有很多問題是不能自動修復(fù)的。比如時間不一致，而又沒有 ntp；網(wǎng)線壞了。。。這些都需要人工介入修復(fù)問題。而此時的表現(xiàn)就是有問題的節(jié)點反復(fù)重啟。
從 Oracle10g 起，Oracle 提供了自己的集群軟件，叫做 Oracle Clusterware，簡稱 CRS，這個軟件是安裝 oraclerac 的前提，而上述第三方集群則成了安裝的可選項 。同時提供了另外一個新特性叫做 ASM，可以用于 RAC 下的共享磁盤設(shè)備的管理，還實現(xiàn)了數(shù)據(jù)文件的條帶化和鏡像，以提高性能和安全性 (S.A.M.E: stripe and mirroreverything ) ，不再依賴第三方存儲軟件來搭建 RAC 系統(tǒng)。尤其是 Oracle11gR2 版本不再支持裸設(shè)備，Oracle 將全力推廣 ASM，徹底放棄第三方集群組件支持。
Oracle Clusterware 使用兩種心跳設(shè)備來驗證成員的狀態(tài)，保證集群的完整性。
兩種心跳機制都有一個對應(yīng)的超時時間，分別叫做 misscount 和 disktimeout：
reboottime ，發(fā)生裂腦并且一個節(jié)點被踢出后，這個節(jié)點將在reboottime 的時間內(nèi)重啟;默認是 3 秒。用下面的命令查看上述參數(shù)的實際值：
在下面兩種情況發(fā)生時，css 會踢出節(jié)點來保證數(shù)據(jù)的完整，：
(一) Private Network IO time > misscount，會發(fā)生 split brain 即裂腦現(xiàn)象，產(chǎn)生多個“子集群”(subcluster) ，這些子集群進行投票來選擇哪個存活，踢出節(jié)點的原則按照下面的原則：節(jié)點數(shù)目不一致的，節(jié)點數(shù)多的 subcluster 存活;節(jié)點數(shù)相同的，node ID 小的節(jié)點存活。
(二) VoteDisk I/O Time > disktimeout ，踢出節(jié)點原則如下：失去半數(shù)以上 vote disk 連接的節(jié)點將在 reboottime 的時間內(nèi)重啟。例如有 5 個 vote disk，當由于網(wǎng)絡(luò)或者存儲原因某個節(jié)點與其中>=3 個 vote disk 連接超時時，該節(jié)點就會重啟。當一個或者兩個 vote disk 損壞時則不會影響集群的運行。
對于一個已經(jīng)有的系統(tǒng)，可以用下面幾種方法來確認數(shù)據(jù)庫實例的心跳配置，包括網(wǎng)卡名稱、IP 地址、使用的網(wǎng)絡(luò)協(xié)議。
? 最簡單的方法，可以在數(shù)據(jù)庫后臺報警日志中得到。使用 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
找到對應(yīng) trace 文件的這一行：socket no 7 IP 10.0.0.55 UDP 16878
? 從數(shù)據(jù)字典中得到：
SQL> select * from v$cluster_interconnects;
SQL> select * from x$ksxpia;
為了避免心跳網(wǎng)絡(luò)成為系統(tǒng)的單一故障點，簡單地我們可以使用操作系統(tǒng)綁定的網(wǎng)卡來作為 Oracle 的心跳網(wǎng)絡(luò)，以 AIX 為例，我們可以使用 etherchannel 技術(shù)，假設(shè)系統(tǒng)中有 ent0/1/2/3 四塊網(wǎng)卡，我們綁定 2 和 3 作為心跳：在 HPUX 和 Linux 對應(yīng)的技術(shù)分別叫 APA 和 bonding
UDP 私有網(wǎng)絡(luò)的調(diào)優(yōu)當使用 UDP 作為數(shù)據(jù)庫實例間 cache fusion 的通信協(xié)議時，在操作系統(tǒng)上需要調(diào)整相關(guān)參數(shù)，以提高 UDP傳輸效率，并在較大數(shù)據(jù)時避免出現(xiàn)超出 OS 限制的錯誤：
(一) UDP 數(shù)據(jù)包發(fā)送緩沖區(qū)：大小通常設(shè)置要大于(db_block_size * db_multiblock_read_count )+4k，
(二) UDP 數(shù)據(jù)包接收緩沖區(qū)：大小通常設(shè)置 10 倍發(fā)送緩沖區(qū);
(三) UDP 緩沖區(qū)最大值：設(shè)置盡量大(通常大于 2M)并一定要大于前兩個值;
各個平臺對應(yīng)查看和修改命令如下：
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
...............................................................................................................................
● 本文整理自網(wǎng)絡(luò)
● 本文在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/
● 數(shù)據(jù)庫筆試面試題庫及解答：http://blog.itpub.net/26736162/viewspace-2134706/
● QQ群：230161599 微信群：私聊
● 聯(lián)系我請加QQ好友(646634621)，注明添加緣由
● 于 2017-06-02 09:00 ~ 2017-06-30 22:00 在魔都完成
● 文章內(nèi)容來源于小麥苗的學習筆記，部分整理自網(wǎng)絡(luò)，若有侵權(quán)或不當之處還請諒解
● 版權(quán)所有，歡迎分享本文，轉(zhuǎn)載請保留出處
...............................................................................................................................
拿起手機使用微信客戶端掃描下邊的左邊圖片來關(guān)注小麥苗的微信公眾號：xiaomaimiaolhr，掃描右邊的二維碼加入小麥苗的QQ群，學習最實用的數(shù)據(jù)庫技術(shù)。
免責聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號
手機網(wǎng)站二維碼
