【文章內(nèi)容簡介】 與： IP 是利用TCP層超時(shí)， VIP 利用的是應(yīng)用層的立即響應(yīng)。VIP 它是浮動(dòng)的IP. 當(dāng)一個(gè)節(jié)點(diǎn)出現(xiàn)問題時(shí)會(huì)自動(dòng)的轉(zhuǎn)到另一個(gè)節(jié)點(diǎn)上。假設(shè)有一個(gè)2個(gè)節(jié)點(diǎn)的RAC，正常運(yùn)行時(shí)每個(gè)節(jié)點(diǎn)上都有一個(gè)VIP。 VIP1 和VIP2. 當(dāng)節(jié)點(diǎn)2發(fā)生故障，比如異常關(guān)系。 RAC 會(huì)做如下操作：1). CRS 在檢測到rac2節(jié)點(diǎn)異常后，會(huì)觸發(fā)Clusterware 重構(gòu)，最后把rac2節(jié)點(diǎn)剔除集群，由節(jié)點(diǎn)1組成新的集群。2). RAC的Failover 機(jī)制會(huì)把節(jié)點(diǎn)2的VIP轉(zhuǎn)移到節(jié)點(diǎn)1上，這時(shí)節(jié)點(diǎn)1的PUBLIC 網(wǎng)卡上就有3個(gè)IP 地址： VIP1,VIP2, PUBLIC IP1.3). 用戶對VIP2的連接請求會(huì)被IP層路由轉(zhuǎn)到節(jié)點(diǎn)14). 因?yàn)樵诠?jié)點(diǎn)1上有VIP2的地址，所有數(shù)據(jù)包會(huì)順利通過路由層，網(wǎng)絡(luò)層，傳輸層。5). 但是，節(jié)點(diǎn)1上只監(jiān)聽VIP1和public IP1的兩個(gè)IP地址。并沒有監(jiān)聽VIP2，故應(yīng)用層沒有對應(yīng)的程序接收這個(gè)數(shù)據(jù)包，這個(gè)錯(cuò)誤立即被捕獲。6). 客戶段能夠立即接收到這個(gè)錯(cuò)誤，然后客戶段會(huì)重新發(fā)起向VIP1的連接請求。 VIP 特點(diǎn)： 1). VIP 是通過VIPCA腳本創(chuàng)建的 2). VIP 作為Nodeapps類型的CRS Resource 注冊到OCR中，并由CRS 維護(hù)狀態(tài)。 3). VIP 會(huì)綁定到節(jié)點(diǎn)的public 網(wǎng)卡上，故public 網(wǎng)卡有2個(gè)地址。 4). 當(dāng)某個(gè)節(jié)點(diǎn)發(fā)生故障時(shí)，CRS 會(huì)把故障節(jié)點(diǎn)的VIP 轉(zhuǎn)移到其他節(jié)點(diǎn)上。5). 每個(gè)節(jié)點(diǎn)的Listener 會(huì)同時(shí)監(jiān)聽public 網(wǎng)卡上的 public ip 和VIP6). 一般會(huì)配置指向節(jié)點(diǎn)的VIP. Clusterware 的日志體系Oracle Clusterware的輔助診斷，只能從log 和trace 進(jìn)行。 而且它的日志體系比較復(fù)雜。 :$ORA_CRS_HOME\log\hostname\, 這是首選的查看文件。Clusterware后臺(tái)進(jìn)程日志：: $ORA_CRS_HOME\log\hostname\crsd\: $ORA_CRS_HOME\log\hostname\cssd\: $ORA_CRS_HOME\log\hostname\evmd\Nodeapp日志位置：$ORA_CRS_HOME\log\hostname\racg\這里面放的是nodeapp的日志，包括ONS和VIP，比如：工具執(zhí)行日志：$ORA_CRS_HOME\log\hostname\client\Clusterware 提供了許多命令行工具： 比如ocrcheck, ocrconfig,ocrdump,oifcfg和clscfg, 這些工具產(chǎn)生的日志就放在這個(gè)目錄下還有$ORACLE_HOME\log\hostname\client\ 和$ORACLE_HOME\log\hostname\racg 也有相關(guān)的日志。 一． RAC 并發(fā)RAC 的本質(zhì)是一個(gè)數(shù)據(jù)庫，運(yùn)行在多臺(tái)計(jì)算機(jī)上的數(shù)據(jù)庫，它的主要任務(wù)是數(shù)據(jù)庫就是事務(wù)處理，它通過 Distributed Lock Management(DLM:分布式鎖管理器) 來解決并發(fā)問題。因?yàn)镽AC的資源是共享的，為了保證數(shù)據(jù)的一致性，就需要使用DLM來協(xié)調(diào)實(shí)例間對資源的競爭訪問。RAC 的DLM 就叫作 Cache Fusion。在DLM 中，根據(jù)資源數(shù)量，活動(dòng)密集程度，把資源分成兩類：Cache Fusion和NonCache Fusion。Cache Fusion Resource指數(shù)據(jù)塊這種資源，包括普通數(shù)據(jù)庫，索引數(shù)據(jù)庫，段頭塊(Segment Header),undo 數(shù)據(jù)庫。 NonCache Fusion Resource是所有的非數(shù)據(jù)庫塊資源, 包括數(shù)據(jù)文件，控制文件，數(shù)據(jù)字典，Library Cache，share Pool的Row Cache等。Row Cache 中存放的是數(shù)據(jù)字典，它的目的是在編譯過程中減少對磁盤的訪問。在Cache Fusion中，每一個(gè)數(shù)據(jù)塊都被映射成一個(gè)Cache Fusion資源，Cache Fusion 資源實(shí)際就是一個(gè)數(shù)據(jù)結(jié)構(gòu)，資源的名稱就是數(shù)據(jù)塊地址（DBA）。每個(gè)數(shù)據(jù)請求動(dòng)作都是分步完成的。首先把數(shù)據(jù)塊地址X轉(zhuǎn)換成Cache Fusion 資源名稱，然后把這個(gè)Cache Fusion 資源請求提交給DLM， DLM 進(jìn)行Global Lock的申請，釋放活動(dòng)，只有進(jìn)程獲得了PCM Lock才能繼續(xù)下一步，即：實(shí)例要獲得數(shù)據(jù)塊的使用權(quán)。Cache Fusion要解決的首要問題就是：數(shù)據(jù)塊拷貝在集群節(jié)點(diǎn)間的狀態(tài)分布圖， 這是通過GRD 實(shí)現(xiàn)的。 GRD（Global Resource Directory）可以把GRD 看作一個(gè)內(nèi)部數(shù)據(jù)庫，這里記錄的是每一個(gè)數(shù)據(jù)塊在集群間的分布圖，它位于每一個(gè)實(shí)例的SGA中，但是每個(gè)實(shí)例SGA中都是部分GRD，所有實(shí)例的GRD匯總在一起就是一個(gè)完整的GRD。RAC 會(huì)根據(jù)每個(gè)資源的名稱從集群中選擇一個(gè)節(jié)點(diǎn)作為它的Master Node，而其他節(jié)點(diǎn)叫作Shadow Node。 Master Node 的GRD中記錄了該資源在所有節(jié)點(diǎn)上的使用信息，而Shadow Node的GRD中只需要記錄資源在該節(jié)點(diǎn)上的使用情況，這些信息實(shí)際就是PCM Lock信息。PCM Lock 有3個(gè)屬性： Mode，Role 和 PI(Past Image)二． RAC 架構(gòu) SGA 的變化 和傳統(tǒng)的單實(shí)例相比， RAC Insance的SGA 最顯著的變化就是多了一個(gè)GRD部分。 Oracle 中的數(shù)據(jù)操作都是在內(nèi)存的SGA區(qū)完成的，和傳統(tǒng)的單實(shí)例不同，RAC 是有多個(gè)，每個(gè)數(shù)據(jù)塊可以在任何一個(gè)Instance 的SGA中都有拷貝，RAC必須知道這些拷貝的分布版本，狀態(tài)，而GRD就是這些信息的內(nèi)存區(qū)。GRD 雖然位于SGA中，但是不像Buffer Cache 或者 Log buffer等SGA 組件，有明確的參數(shù)來對應(yīng)，每個(gè)節(jié)點(diǎn)中都只有部分GRD內(nèi)容，所有的節(jié)點(diǎn)合在一起才構(gòu)成完整的GRD. 后臺(tái)進(jìn)程的變化 每個(gè)RAC的實(shí)例和傳統(tǒng)的單實(shí)例一樣，都有DBWR,LGWR,ARCn，CKPT 這些后臺(tái)進(jìn)程，除了這些進(jìn)程外，每個(gè)實(shí)例還增加了若干RAC特有的進(jìn)程，要注意的是，這些進(jìn)程名稱和進(jìn)程提供的服務(wù)名稱差異很大，比如LMS進(jìn)程提供的是GCS 服務(wù)，很不便與記憶，造成這種現(xiàn)象的原因是進(jìn)程名稱從9i 之前的OPS（RAC 前身）延續(xù)下來的，但是服務(wù)卻已經(jīng)在RAC中重新設(shè)計(jì)并命名。 LMSn 這個(gè)進(jìn)程是Cache Fusion的主要進(jìn)程，負(fù)責(zé)數(shù)據(jù)塊在實(shí)例間的傳遞，對應(yīng)的服務(wù)叫作GCS(Global Cache Service), 這個(gè)進(jìn)程的名稱來源與Lock Manager Service。 從Oracle 9開始，Oracle 對這個(gè)服務(wù)重新命名成Global Cache SErvice, 但是進(jìn)程名字確沒有