Oracle RAC的優勢在於利用多個節點（數據庫實例）組成一個數據庫，這樣在保證了數據庫高可用性的情況下更充分的利用了多個主機的性能，而且可以通過增加節點進行性能的擴展。實現Oracle RAC需要解決的關鍵問題就是多節點進行數據訪問時如何保證數據的一致性，Oracle是通過各節點間的私有連接進行內存融合（cache fusion）來保證各節點數據訪問的一致性。用一個例子來解釋一下內存融合的過程，在存在A、B兩個節點的RAC環境中，當A節點使用DML語句（如Update）對一個數據塊中的數據進行修改時，A節點實例會到GRD（Global Resource Directory）中查找該數據塊的信息，這些信息包括該數據塊的Master（第一次讀這個數據塊的節點），Owner（當前擁有這個數據塊的節點），以及數據塊在各個節點間的傳遞記錄。A節點如果發現GRD中沒有需要讀取的數據塊的信息，說明該數據塊是一個干凈的數據塊，A節點從磁盤或Buffer Cache中獲得該數據塊，然后對需要修改的行加鎖，進行相應的修改，當然SCN會隨之增加。在A完成修改而沒有提交或回滾的情況下，如果B節點也需要訪問這個數據塊修改某些行（假設不同於A修改的行），B同樣去到GRD中查找該數據塊的信息，當然B發現該數據塊的Master為A，Owner也為A，為了保證A的修改不丟失，B需要發信息給A，讓A將需要修改的數據塊通過私有連接直接從內存中傳給B，當然該數據塊中包含A的鎖信息，這樣A節點與B節點間的一次內存的數據傳遞就是內存融合。Oracle RAC的內存融合也面臨一些問題，繼續剛剛的例子，如果A又再次請求對該數據塊修改或者結束事務（提交或回滾）的時候，又需要從B節點內存中取得數據塊，又要發生內存融合，這樣在兩個節點業務沒有合理分割的情況下，數據庫繁忙時，大量的內存融合會對數據庫性能造成嚴重的影響。通過對Oracle RAC技術的理解，在實現Oracle RAC架構時的業務分割就成為了保證系統性能的重要手段，業務分割的根本在於使不同的實例不能訪問相同的數據塊，這樣業務分割規則可以小到表的級別（不同的表不會共享一個數據塊），大到表空間、Schema的級別。心跳應該用獨立的網卡。
當然，rac本身之保證了數據庫服務器的高可用和高性能，所以最好有其他的存儲技術來保證存儲的高可用，例如raid\vplex等。
在距離不太遠（幾十公里），且速度較快（例如裸光纖）下，延時較小，，米足夠多，可以考慮使用oracle rac實現雙活或者災備，RTO RPO=0。
附：
1.rac基本理論知識
1.1 Public NIC接入公共網絡，private NIC接入私有網絡，這是個完全隔離的網絡傳遞的數據只是RAC節點的心跳數據和cache fusion數據。oracle不建議私有網絡直接用交叉線連接。
1.2 RAC最重要的是共享存儲。數據文件、聯機日志、控制文件、參數文件都必須放在共享存儲上。現在的存儲環境基本上都是基於SAN的，跑FC協議（FC協議封裝了SCSI協議）。
1.3 RAC環境需要OS必須版本相同包括小版本、補丁包都必須一致。
1.4 集群件安裝在OS之上，負責管理整個集群環境中的硬件資源並為上層的RAC集群提供基礎服務。如果把集群看成是一台虛擬的計算機，那么集群件就是這台計算機上的OS，而RAC是運行在其上的一個應用。
10g之前，oracle只針對linux、windows兩個OS提供了一個不完善的集群件產品OCM（oracle cluster manager），其它平台需要第三方集群產品比如HACMP、sun cluster。10g開始，10.1版本提供CRS，10.2版 本提供oracle clusterware（10.1的改名）。10.2開始的集群件提供API接口，因此還能夠為其它軟件提供HA功能。CRS可以和其它集群件產品集成。10g之前oralce只提供對裸設備的支持，所以9i RAC裸設備是常見選擇。10后oracle提供OCFS和ASM兩種存儲方案。
1.5 OEL(oracle enterprise linux)是oracle在RHEL基礎上重新開發出的linux。
1.6 需要強調的是，10g的clusterware的vote disk、ocr在目前的版本上還只能創建在裸設備、ocfs上。VIP在clusterware安裝過程中創建（調用VIPCA)，不需要手工設置。
1.7 集群的分類：高性能計算集群（用在科學計算）、LB、HA、
1.8 健忘症：集群環境配置文件不是集中存放，每個節點都有一個本地副本，用戶修改任何節點的集群配置會將更改同步到其它節點。但這樣有一個問題：節點1正常維護需要關閉，然后在節點2修改了配置，然后節點2關閉，啟動節點1，由於沒有同步，所以節點1啟動后，它用的仍然是舊的配置文件，這時就造成配置丟失，這就叫健忘症。RAC的解決方案是OCR。
1.9 腦裂:節點間了解彼此的健康狀況是通過心跳機制來實現的。如果僅僅是心跳出了問題，各節點還正常運行，這時每個節點都認為其它節點宕機，自己是集群環境的唯一健在者自己應該獲得集群的控制權，因為存儲是共享的，這意味着數據災難。這就叫腦裂。RAC解決腦裂的方法是引入Quorum disk，誰先得到quorum disk這一票誰獲勝，另一個節點被踢出集群。
1.10 IO隔離：解決被踢出集群的節點不能操作共享存儲上的數據。
1.11 CRS resource：CRS對運行於其上的應用進行監視，並在發生異常時進行重啟、切換等干預手段。這些被CRS監控的對象就叫CRS resource。這些resource是在RAC安裝過程中自動或手動創建的，並且注冊登記到CRS中，以metadata的形式被記錄在OCR磁盤上，這些metadata包括resource的名稱、如何啟動、停止、如何檢查健康狀況等配置信息。RAC的CRS resource包括GSD、ONS、VIP、database、instance、listener等。
1.12 oracle clusterware的運行環境由兩個磁盤文件、若干后台進程及網絡元素組成。OCR解決健忘問題，OCR位於共享存儲上保存整個群集的配置，無論在哪個節點修改配置都是修改相同的配置文件。配置信息以“key-value的形式保存其中，10g以前這個文件叫server manageability repository（SRVM)。OCR的位置記錄在ocr.loc文件中，9i對應的是srvConfig.loc文件。
1.13 能讀寫OCR disk中內容的節點稱OCR master。這個節點的OCR process負責更新本地和其它節點的OCR cache。其它節點想修改OCR需要向本節點的OCR process提出請求，然后本節點的process再向OCR master的OCR process提出請求。
1.14 voting disk主要記錄節點成員狀態，在出現腦裂時，仲裁哪個partion獲得集群的控制權。它的位置可以用這個命令來查看：$crsctl query css votedisk
1.15 clusterware最重要的三個后台進程：CRSD、CSSD、EVMD。在安裝clusterware的最后階段會要求在每個節點執行root.sh，目的是在/etc/inittab文件中添加三行使每次系統重啟時，cluseter也會自動啟動。EVMD和CRSD兩個進程如果出現異常，系統會自動重啟這兩個進程。如果CSSD出現異常，系統會立即重啟。
OCSSD進程：該進程提供CSS（cluster synchronization service）服務，CSS服務通過多種心跳機制實時監控集群健康狀態，提供腦裂保護等基礎集群服務功能。心跳機制包含兩種：私有網絡、voting disk。
兩個心跳都有最大時延，對於disk heartbeat，這個時延叫IOT，對於network heartbeat，這個時延叫MC，兩個參數都是以秒為單位，缺省IOT大於MC。可以通過以下命令來查看這兩個參數：
$crsctl get css disktimeout $crsctl get css misscount
另外這個進程還用來支持ASM instance和RDBMS instance之間的通信。如果在已經安裝了ASM的節點上安裝RAC，會遇到一個問題，RAC要求節點只有一個OCSSD進程，並且是運行在$CRS_HOME目錄下的。這就需要先停止ASM，並通過$ORACLE_HOME/bin/localconfig.sh delete刪除之前的inittab條目。
CRSD進程：實現HA的主要進程，它所提供的服務叫CRS（cluster ready service）它監控資源，並在資源運行異常時進行干預，包括關閉、重啟進程或轉移服務。默認情況下，CRS會自動嘗試重啟資源5次，如果還是失敗則放棄嘗試。
EVMD進程：負責發布CRS產生的各種事件，這些event可以通過兩種方式發布給客戶--ONS和callout script。另外它還負責CRSD和CSSD兩個進程間的通信。
RACGIMON進程：負責檢查數據庫健康狀態，負責service的啟動、停止、故障轉移，這個進程會建立到數據庫的持久連接，定期檢查SGA中的特定信息，該信息由PMON進程定時更新。
OPROCD進程：也叫process monitor daemon。在非linux平台且沒有使用第三方集群軟件時，會看到這個進程，用來檢測節點的CPU掛起，如果調度時間超過1.5S，會認為CPU工作異常，會重啟節點。在linux平台上時候時利用hangcheck-timer模塊來實現IO隔離功能的。
1.16 IP利用的是TCP層超時，VIP利用的是應用層的立即響應。詳見P94。
1.17 clusterware的日志體系比較復雜，日志的根目錄在$CRS_HOME/log/[node]
1.18 單實例下的並發控制
lock框架包括3個組件：資源、鎖、排隊機制。前兩者是數據結構，后者是使用算法。
資源：由owner、waiter、converter三個成員組成，這是3個指針分別指向lock組成的鏈表。
鎖：當要訪問共享資源時，需要鎖定資源。如果不能獲得資源的訪問權，就把lock掛到資源的waiter鏈表中，如果能獲得就掛到lock的owner鏈表中。
排隊機制：lock使用的是enqueue的算法即“先入先出隊列”。如進程的鎖定不能滿足，該進程的lock structure就被加到waiter鏈表的末端。
waiter和converter排隊機制的區別：如果某個操作需要先后兩種不同模式的鎖，比如先share mode然后exclusive mode，則進程先請求share mode，獲得后的lock structure會掛在owner上，當需要exclusive mode鎖時，進程必須先釋放share mode的鎖，然后再次申請exclusive mode的鎖，但是可能無法立即獲得，這時這個請求就會被掛在converter隊列下，converter隊列會優先於waiter隊列被處理。可以從v$lock看到這些lock信息。
LMODE>0,REQUEST=0 Owner
LMODE=0,REQUEST>0 Waiter（Acquirer）
LMODE>0,REQUEST>0 Converter
對於粗粒度或數量有限的資源使用這種機制還可以，但對於幾百G的數據量，如果每條記錄都分配一個resourece、lock數據結構，無論從內存需求還是維護開銷都是一個噩夢。對於數據記錄這種細粒度資源，oracle使用的是行級鎖。行級鎖其實只是數據塊頭、數據記錄頭的一些字段，不會消耗資源。所以它雖然有鎖的功能，但無鎖的開銷。詳見書的P102。
latch於lock的對比：latch請求、獲得、釋放等操作是原子操作，一般幾個硬件指令就可以完成。lock相反。進程申請lock沒有獲得，這個進程會釋放CPU資源，也就是進行上下文切換，整個過程較耗資源。如果進程申請latch沒有獲得，進程不釋放CPU資源，而是不斷的嘗試請求，只有嘗試了一定次數之后還不能獲得，才釋放CPU，這就是latch的spin機制。這時的表現是：CPU利用率非常高，但吞吐量卻很低。另外latch使用的是搶占機制，而不是lock使用的排隊機制。
1.19 DLM（分布式鎖管理）：可以把它想象成一個仲裁，它記錄着哪個節點正在用哪種方式操作哪個數據，並負責協調解決節點間的競爭。DLM在不同的階段有不同的名稱，OPS的叫PCM，RAC的叫cache fusion。
Non-Cache Fusion資源：典型的資源包括sharepool的row cache和library cache內容。通過每個節點的LCK0進程來同步。
Cache Fusion資源：buffer cache的數據塊。數據塊的狀態可以從v$BH視圖查看。
以上兩種資源可以通過v$resource_limit來查看。
1.20 GRD：記錄每個數據塊在集群間的分布圖。每個實例SGA中都是部分GRD，所有實例的GRD構成一個完整的GRD。
1.21 PCM lock：GRD中記錄的是PCM lock信息，這種鎖有3個屬性：Mode、Role、PI。Role這個屬性是用來描述臟數據塊在集群間分布狀況的，有local和global兩個取值。有local role的實例可以把數據塊寫到磁盤不需要聯系GRD，由本實例完成即可。擁有local role和X mode的實例要給其它instance發送這個數據塊，如果發送的是和磁盤一致的版本，那么本實例任然保持local role。如果發送的是和磁盤不一致的版本，那么本實例的角色就轉換成global，同時接收方也是global，代表多個實例擁有臟數據塊版本。擁有global role的實例想把數據塊寫到磁盤，必須要聯系GRD，由擁有數據塊current版本的實例完成寫動作。
PI: past image，代表着這個實例的SGA中是否擁有和磁盤內容不一致的版本，以及版本順序，並不是代表這個節點是否曾經修改過這個數據塊。PI主要能夠加速crash recovery的恢復過程。
AST: DLM使用兩個隊列跟蹤所有的lock請求，並用兩個ASTs(異步中斷或陷阱）來完成請求的發送和響應。具體的過程見書的P120。
1.22 RAC進程名稱和進程提供的服務名稱差異很大，不便記憶。造成這種現象是因為進程名稱是從OPS時代延續下來的，但是服務名稱卻已經在RAC中重新設計並命名。
LMSn：負責數據塊在實例間的傳遞，對應的服務叫GCS（global cache service）。進程的數據量通過參數GCS_SERVER_PROCESSES控制，默認是2，取值范圍為：0-9。
LMD: 負責在多個實例之間協調對數據塊的訪問順序，保證數據的一致性訪問。它負責提供GES（global enqueue service）服務。GCS、GES、GRD構成RAC最核心的功能：cache fusion。
LCK：負責non-cache fusion資源的同步訪問，每個實例有一個LCK進程。
LMON: 各實例的LMON進程會定期通信，以檢查集群中各節點的健康狀態，當某個節點出現故障時，負責集群重構、GRD恢復等操作，它提供的服務叫CGS（cluster group services）。LMON可以和下層的clusterware合作也可以單獨工作。當LMON檢測到實例級別的腦裂時，LMON會通知下層的clusterware，期待clusterware解決腦裂問題，但是RAC並不假設clusterware肯定能夠解決問題，因此，LMON不會無盡等待clusterware層的處理結果。如果發生等待超時，LMON會自動觸發IMR（instance membership recovery）IMR功能可以看做是oracle在數據庫層提供的腦裂、IO隔離機制。LMON主要是借助兩種心跳機制來完成健康檢測：1、節點間的網絡心跳。2、控制文件的磁盤心跳。每個節點的CKPT進程每隔3S更新一次控制文件一個數據塊。可以通過x$kcccp看到這個動作。SQL>select inst_id,cphbt from x$kcccp
DIAG: 監控實例的健康狀態，並在實例出現運行錯誤時收集診斷數據記錄到alert.log
GSD: 負責從客戶端工具，比如srvctl接收用戶命令，為用戶提供管理接口。
1.23 RAC中的文件。
spfile文件：放在共享存儲
redo thread： 每個實例有套redo log，這套redo log叫做一個redo thread。RAC中每個實例要設置thread參數，該參數缺省值時0。如果設置了這個參數，則實例啟動時，會用等於該thread的private redo thread。如果用缺省值，實例啟動會選擇使用public redo thread，並且該實例會以獨占的方式使用該redo thread。RAC環境下，redo log group是在整個數據庫級別進行編號的，比如實例1有1，2，3三個日志組，那么實例2的日志組就應該從4開始編號。
歸檔日志：歸檔日志不必放在共享存儲上，每個實例可以在本地存放歸檔日志，但是如果在單個實例進行備份歸檔日志或進行介質恢復操作，又要求這個節點能夠訪問到所有實例的歸檔日志。因此RAC環境下配置歸檔日志有多種選擇：1、NFS。2、實例間歸檔。3、ASM。常用第二種方法進行配置。
undo表空間：每個實例都需要一個單獨的回滾表空間。
1.24 RAC中的SCN。在單實例環境中只有一個SCN產生器，改變發生的順序就是SCN的順序。在RAC下，每個節點都有自己的SCN發生器，必須有某種機制保證這些SCN在時間排序上的精確。RAC中GCS負責維護全局的SCN產生，缺省用的時Lamport SCN生成算法。原理如下：節點間通信內容中都攜帶SCN，每個節點把接收到的SCN和本機的SCN比，如果本機的SCN小，則調整本機的SCN和接收到的一致。如果節點間通信不多，還會主動定期互相通報，因此節點即使處於idle狀態，還是會有一些redo log的產生。另外一種算法是廣播算法。原理：每個commit操作后，節點向其它節點廣播SCN，雖然會對系統造成負載，但是確保每個節點在commit后都能看到SCN號。10g RAC就是用的廣播算法，可以在alert.log中看到。
1.25 當不同的實例請求相同的數據塊，這個數據塊就需要在實例間進行傳遞。oracle7的OPS中，這種傳遞是通過磁盤完成的。實例1必須先把這個塊寫回磁盤，然后實例2再從磁盤讀取這個數據塊。oracle8i只能傳遞沒有修改過的數據塊，對於修改的數據塊還是要通過磁盤傳遞。9i才使用cache fusion通過私有網絡傳遞數據塊。
1.26 RAC和clusterware的交互。RAC集群和節點集群是兩個層次的集群，兩個集群都有腦裂，IO隔離等問題。這兩個集群有各自的故障檢測機制，二者之間的機制可以有重疊也可以不同。RAC的集群狀態維護是由RAC的LMON進程提供的，這個進程提供了CGS和NM（node management）兩個服務。NM是RAC集群和clusterware集群的通信通道，通過它把本節點的資源狀態登記到本地的clusterware，進而由后者提供給其它節點的clusterware，NM還要從clusterware獲得其它節點的資源狀態。
NM組：RAC的每個實例的所有進程是作為一個組注冊到clusterware中的，其中LMON進程作為組里的primary member注冊並獲得Member ID，而其它進程作為這個組的slave Member並以相同的member id注冊到clusterware。整個集群的節點成員信息是通過一個位圖來維護的，每個節點對應一個bit，0代表節點down，1代表up，整個位圖有個有效/無效標志位。這個位圖在整個集群中作為一個全局資源被永久記錄。當有新的節點加入集群時，該節點需要讀取該位圖，找到對應的bit，把值從0改變成1，並且把位圖的無效標志位置為1，這時雖然位圖內容是正確的，但狀態是無效的，其它節點發現這個狀態位圖無效，就會觸發集群的重構，達到新的穩態后，再把位圖狀態置為有效，當集群完成重構后，NM會把這個事件傳遞給CGS層，CGS負責同步所有節點間的重構。對於實例的正常啟動和關閉，該實例的NM會向clusterware進行注冊或取消注冊，注冊過程中，NM同時從clusterware獲得集群的其它節點列表，然后NM通知其它節點的NM，最后NM事件發送給CGS層，由CGS層負責協調整個集群的組重構，當CGS完成了重構之后，再通知GCS，GES進行實例重構（GRD層的重構）。對於實例的異常關閉，clusterware、NM就不會知道，這時就需要CGS提供的IMR功能進行感知，然后進行重構。
IMR的重構原理：IMR是由CGS提供的重構機制，用於確認實例之間的連通性、快速的排除故障節點以減少對數據的損害。在這個過程中，每個實例都需要做出投票，投票的內容是它所認為的整個集群現在的狀態，然后由一個實例根據這些投票，重新規划出一個新的集群，並把這個投票結果記錄到控制文件，其它實例讀取這個結果，確認自己是否還屬於集群，如果不屬於集群，就要自動重啟，如果屬於集群則參與重構。IMR發現出現腦裂，即集群中出現兩個group，這時IMR會先通知CM，然后等待CM去解決這個問題，等待時間是_IMR_SPLITBRAIN_RES_WAIT，缺省600毫秒，超時后IMR自己執行節點排除。在CGS完成節點的重構后，GCS，GES才進行數據層面的重構，也就是crash recovery。
重構觸發類型：1,節點的加入或離開，由NM觸發。2,網絡心跳異常，超時時間默認300S，由_cgs_send_timeout參數控制，由IMR觸發。3，控制文件心跳異常，超時時間默認900S，由_controlfile_enqueue_timeout參數控制，由IMR觸發。
2.ASM存儲方案
2.1red hat as4以后，裸設備已經被linux社區拋棄了，而是通過支持O_DIRECT標識來繞過OS緩沖。10gR2缺省就是用O_DIRECT的方式操作設備的。但是oracle clusterware 10R2的開發沒能及時跟上，仍然需要使用裸設備來創建voting disk和OCR。
2.2 ASM中的shared pool有extent map，每100GB需要1MB的extent map，根據這個空間再加上額外的2MB就可以了，ASM SGA的默認值一般能滿足要求。
2.3 ASM實例比RDBMS多出兩個進程：RBAL和ABRn
RBAL：rebalancer進程，負責規划ASM磁盤組的reblance活動。
ABRn：RBAL的子進程，數量上可以有多個1-9，這組進程負責真正完成reblance活動。
2.4 使用ASM作為存儲的RDBMS實例，會多出兩個進程：RBAL和ASMB
RBAL:打開每個磁盤組的所有磁盤和數據的rebalance。
ASMB:負責與ASM實例的通信，它先利用diskgroup name從CSS獲得管理改diskgroup的ASM實例的連接串，然后建立到ASM的持久連接，兩個實例通過這條連接定期交換信息，同時也是一種心跳機制。
RDBMS要想使用ASM作為存儲，必須在啟動時從ASM實例獲得extent map，以后發生磁盤組的維護操作，ASM實例還要把extent map的更新信息通知給RDBMS，這兩個實例間的信息交互就是通過ASMB進程完成的。因此ASM實例必須先於數據庫實例的啟動。
O0nn 01-10：這組實例建立到ASM實例的連接，某些長時間操作比如創建數據文件，RDBMS會通過這些進程向ASM發送信息。
2.5 ASM實例運行不需要任何文件只是表面現象，其實ASM也需要很多文件來保證它的運行，只不過這些文件是oracle內部維護的，對DBA不可見，也不需要DBA的干預。
2.6 ASM實例和RDBMS是1：1的關系，兩個實例可以共用一個$ORACLE_HOME。ASM和RDBMS是1：n的關系，則最好為ASM安裝單獨的ASM_HOME，並和RDBMS的ORACLE_HOME區分開來，這種環境需要使用ASM_HOME下的監聽器。
2.7 創建ASM磁盤：首先要讓ASM實例發現磁盤，另外要讓磁盤分區的屬主設成oracle。接下來就是創建ASM磁盤，ASM可以通過兩種方式使用磁盤，一是裸設備方式，二是ASMlib方式（允許在塊設備上創建ASM，目前oracle只提供了linux下的ASMlib)。
2.8 使用裸設備。solaris平台下，系統同時提供對磁盤設備的字符（c）、塊（b）方式訪問。每個磁盤有兩個設備文件名（/dev/dsk/c1t1d1s1;/dev/rdsk/c1t1d1s1),創建ASM直接用這些設備名就可以了，無需額外配置裸設備。AIX也是一樣的道理。linux平台比較麻煩，缺省沒有提供對磁盤設備的字符訪問方式，必須配置rawdevices服務，把塊設備綁定到裸設備才行。這里有三種方式來配置。只要區別在於對oracle用戶權限處理方法不同。
方式1：#vi /etc/sysconfig/rawdevices 添加裸設備、塊設備的綁定條目：/dev/raw/raw30 /dev/sdc1 /dev/raw/raw31 /dev/sdc2 ... --> #service rawdevices start --》#chkconfig rawdevices on(系統啟動時，自動啟動rawdevices服務） --》#service rawdevices status --》cd /dev/raw;ll(查看裸設備） --》#cd /dev/raw;chown oracle:dba raw* -->在/etc/rc.local或其它腳本中添加改raw設備屬性的命令。(因為rawdevices是以root運行的，因此裸設備缺省的owner是root:root)
方式2：#mknod /oradata/system.dbf c 162 1(這里的162，1分別是major device number，minor device number） --》#chown oracle：dba /oradata/system.dbf -->#vi /etc/sysconfig/rawdevices
/oradata/system.dbf /dev/sdd7 -->#service rawdevices restart 服務重啟后會在/dev/raw目錄下創建出一個新的裸設備。
方式3：適合在red hat as4使用，這個版本是用UDEV來管理設備，設備啟動后的屬主可以在文件中配置。前面的步驟跟方式一樣，權限的修改步驟如下：#vi /etc/udev/permissions.d/50-udev.permissions 找到raw一節，修改成下面內容：raw/*:oracle:dba:0660 -->#service rawdevices restart RHEL5 UDEV的工作方式又發生了變化，50-udev.permissions 文件被拋棄，而使用rule文件來配置。
2.9 ASMlib方式。ASMlib是一個由ORACLE定義接口、由存儲廠商實現的函數庫，目前oralce只提供了linux平台下的實現庫。下載ASMlib時要選擇和OS內核匹配的版本。安裝完成后，配置驅動（#/etc/init.d/oracleasm configure) ,確認配置成功（#lsmod |grep asm;cat /proc/filesystem;df -ha）。創建ASM磁盤（#/etc/init.d/oracleasm createdisk VOL1 /dev/sdb1 ...),這時能在/dev/oracleasm/disks目錄下看到createdisks創建的磁盤VOL1。列出創建好的磁盤（#/etc/init.d/oracleasm listdisks),進一步查看每個ASM磁盤對應的物理設備（#/etc/init.d/oracleasm querydisk VOL1)。如果是RAC環境，只需要在一個節點上執行，其它節點執行這個命令就可以掃描的磁盤了，#/etc/init.d/oracleasm scandisks。
2.10 如果完全使用裸設備實現RAC，配置存儲的時候有兩點需要注意：1、保證LUN在各節點上的順序一樣。2、設備名對應的物理設備不會因為系統的重啟發生變化。比如sda、sdb這類名字，到底是a還是b取決於總線對硬件的掃描順序。RAC環境中一個節點連着兩套存儲，一套是本地，另一套是通過HBA卡連接的SAN，HBA卡和本地盤的掃描順序決定着這類名字對應的設備的變化。為了避免這種不一致，要在/etc/mobprobe.conf中添加兩行，強迫掃描本地盤，再掃描HBA。（alias scsi_hostadapter1 aic7xxx alias scsi_hostadapter2 lpfc)不過到了RED HAT AS4默認就是這種順序了。如果使用ASM就不需要這些配置，ASM磁盤頭會有metadata信息可以准確的識別磁盤。但是磁盤名稱在所有節點一致仍然是一個好習慣。
2.11 major number，minor number。前者找到設備驅動程序，后者找到設備具體位置。major number，minor number是預先分配好的，比如裸設備的major number是162，SCSI設備的major number是8。SCSI設備的minor number=driver*16 + partition number。SCSI設備的用戶空間名是sd driver partition。linux下SCSI磁盤/dev/sda的partition number是0，代表整個磁盤，linux每個磁盤最多有16個分區，其中分區4代表整個擴展分區，可用分區只有15個。
2.12 配置ASM實例：先介紹幾個初始化參數。ASM_POWER_LIMIT:當在磁盤組中添加或刪除磁盤時，磁盤組會自動對數據在新舊磁盤間重新分配，從而實現分散IO，這個過程叫再平衡（rebalance）。取值范圍0-11。0代表不做rebalance，11代表最快的速度做rebalance，也意味着最嚴重的性能影響。alter diskgroup dg1 add disk 'a' rebalance power 1 (往磁盤組增加一個磁盤a，並定義rebalance為1。）
ASM_DISKSTRING:定義哪些磁盤可以被ASM使用。使用ASMlib時，需要使用”ORCL:磁盤名“格式。ASM實例也可以使用SPFILE。
無論是否在RAC環境，ASM實例都需要CSS進程，否則會報29701的錯誤。啟動CSS進程的命令如下：/oracle/product/10.2.0/db1/bin/localconfig add
創建磁盤組的操作需要連接到ASM實例中進行，記得創建一個spfile文件。SQL>create diskgroup dg1 external redundancy disk 'ORCL:VOL1','ORCL:VOL2';(創建磁盤組dg1）。
現在RDBMS可以使用ASM的磁盤組了。使用前必須保證ASM實例已經注冊到Listener,否則需要手工注冊（SQL>alter system register;)。使用ASM的磁盤組中的磁盤很簡單（SQL>create tablespace test datafile '+dg1/test.dbf' size 100M;)。RDBMS在運行的時候，ASM實例是無法關閉的，手工關閉也不可能。
3.RAC維護工具集
oracle clusterware命令集的分類：
節點層：olsnodes
網絡層：oifcfg
集群層：crsctl ocrcheck ocrdump ocrconfig
應用層：srvctl onsctl crs_stat
oifcfg的4個子命令：iflist;getif;setif;delif 舉例：
$oifcfg iflist --顯示網口列表
$oifcfg getif --查看每個網卡的屬性
$oifcfg getif -global dbp --查看節點dbp的global類型的配置
$oifcfg getif -type public --查看public類型的網卡配置
$oifcfg getif -type cluster_interconnect
$oifcfg setif -global ten@none/10.0.0.1:public --添加新的網卡，這個命令並不會檢查網卡是否真的存在。
$oifcfg delif -global --刪除接口配置
$oifcfg setif -g global eth0/192.168.12.1:public --添加接口配置
$oifcfg setif -g global eth1/10.0.0.0:cluster_interconnect
$crsctl check crs --檢查CRS狀態
$crsctl check cssd/crsd/evmd --分別檢查三個組件的狀態
CRS進程默認隨着OS的啟動而自動啟動，有時出於維護的目的需要停止這個進程，可以用以下命令：
#/oracle/product/oem/crs/bin/crsctl disable/enable crs
這個命令實際上是修改了/etc/oracle/scls_scr/dbp/root/crsstart 這個文件的內容。
啟動、停止CRS棧：crsctl start/stop crs
$crsctl get query css votedisk --查看votedisk磁盤的位置。
$crsctl get css misscount --查看參數
$crsctl set css miscount 100 --設置參數
CRS由CRS、CSS、EVM3個服務組成，每個服務又是由一系列module組成的。CRSCTL允許對每個module進行跟蹤，並把跟蹤內容記錄到日志中。
$crsctl lsmodules css/crs/evm
#/oracle/product/oem/crs/bin/crsctl debug log css "CSSD:1" --跟蹤CSSD模塊。
#more $CRS_HOME/log/dbp/cssd/ocssd.log --查看跟蹤產生的日志。
維護votedisk：可以通過crsctl命令添加votedisk，votedisk使用是的是一種過半數的算法，所以添加votedisk應該添加兩個。添加和刪除votedisk的操作比較危險，必須停止數據庫、停止ASM、停止CRS后操作，並且操作時必須使用-force參數。舉例如何添加一個votedisk：
1.#$ORA_CRS_HOME/bin/crsctl add css votedisk /dev/raw/raw1 -force
#$ORA_CRS_HOME/bin/crsctl add css votedisk /dev/raw/raw2 -force
2.#$ORA_CRS_HOME/bin/crsctl query css votedisk
3.#crsctl start crs
OCR系列命令：ORACLE會每4個小時對OCR做一個備份，並且保留最后3個備份，以及前一天，前一周的最后一個備份。這個備份由master node的CRSD進程完成，備份的默認位置為：$CRS_HOME/crs/cdata/<cluster_name>目錄下，每次備份后，備份文件名會自動更改，最近一次備份叫backup00.ocr。建議DBA除了保存在本地外，還應該在其它地方保存一份。
ocrdump：以ASCII的方式打印出OCR的內容，產生的文件只能用於閱讀，不能用於恢復。
$ocrdump -stdout -keyname SYSTEM.css -xml|more --把SYSTEM.css鍵的內容以.xml格式打印輸出到屏幕。命令的執行過程中，會在$CRS_HOME/log/<nodename>/client目錄下產生名為ocrdump_<pid>.log的日志文件，如果命令出現執行問題，可以查看這個日志。
ocrcheck：用於檢查OCR內容的一致性，不需要參數。這個命令會產生ocrcheck_pid.log日志文件。
ocrconfig：用於維護OCR磁盤，OCR磁盤最多只能有兩個，一個是primary OCR，另一個是Mirror OCR。
$ocrconfig -help --查看命令幫助
$ocrconfig -showbackup --查看自動備份，OCR的自動備份在$CRS_HOME/crs/cdata/<cluster_name>目錄ixa，可以通過ocrconfig -backuploc <directory_name>命令修改到新目錄。
OCR的備份與恢復：oracle推薦在對集群作調整時，比如增加、刪除節點前，應該對OCR做一個備份。可以使用export備份到指定文件。如果做了replace或restore等操作，oracle建議使用cluvfy comp ocr -n all命令做一次全面檢查。下面舉一個OCR備份與恢復的案例：
1.crsctl stop crs
2.ocrconfig -export /oracle/ocr.exp (注意這里要用root用戶導出）
3.crsctl start crs
4.crsctl check crs
5.dd if=/dev/zero of=/dev/raw/raw1 bs=1024 count=102400 (故意破壞ocr內容）
6.ocrcheck --檢查會失敗。
7./backup/install_medir/clusterware/cluvfy/runcluvfy.sh comp ocr -n all --檢查一致性也失敗。
8.ocrconfig -import /oracle/ocr.exp --恢復OCR內容。
9.再次用剛才的兩個工具進行檢查。
10.crsctl start crs
移動OCR的位置：（/dev/raw/raw1移到/dev/raw/raw31)
1.ocrconfig -showbackup / ocrconfig -export /tmp/ocrexp -s online --查看OCR是否有備份，如果沒有執行一次導出做備份。
2.ocrcheck / ocrconfig -replace ocrmirror /dev/raw/raw21 --查看當前OCR的位置，發現只有一個primary ocr，沒有mirror ocr，所以不能直接改變OCR的位置，需要添加鏡像再修改OCR位置。
3.ocrcheck --驗證一下是否添加成功。
4.ocrconfig -replace ocr /dev/raw/raw31 --改變位置。
5.檢查/etc/oracle/ocr.loc文件。系統默認會修改這個文件，如果沒有更改，需要手工修改相應的條目。
crs_stat --查看CRS維護的所有資源的運行狀態，包括2個GSD,ONS,VIP,ASM INSTANCE,LISTENER,RDBMS INSTANCE和1個database。使用-v -p參數可以獲得更詳細的信息。 -ls選項可以獲得每個資源的權限定義。
onsctl --這個命令用於管理配置ONS（oracle notification service），ONS是oracle clusterware實現FAN(fast application notification）Event push模型的基礎。傳統模型中，客戶端需要定期檢索服務器來判斷服務端狀態，本質上是一個PULL模型。10g引入了一種全新的PUSH機制-FAN，當服務端發生某些事件時，服務器會主動的通知客戶端這種變化，這樣客戶端能盡早知道服務端的變化，而這種機制就是依賴ONS實現的。在使用這個命令之前，需要先配置ONS服務。
ONS配置內容：配置文件在$CRS_HOME/opmn/conf/ons.config,注意這個文件中的nodes和useocr這兩個參數。這兩個參數共同決定了本機ONS daemon要和哪些遠程節點上的ONS daemon進行通信。如果useocr=ON，說明信息保存在OCR中，如果是OFF說明信息取nodes中的配置。對於單實例而言，要把useocr設置成OFF。看幾個配置的例子：
useocr=off
nodes=dbs：6200，dbp：6200
（節點信息從nodes參數讀取，本機的ONS要和這dbs，dbp兩個節點上的6200端口通信）
useocr=on
（使用OCR時，這個信息是保存在DATABASE.ONS_HOSTS這個鍵下。可以把這個鍵從OCR導出來：ocrdump -xml abc.xml -keyname DATABASE.ONS_HOSTS)。
可以直接編輯這個配置文件來配置ONS，如果使用了OCR則可以通過racgons命令進行配置。舉個例子：
racgons add_config dbs:6200 dbp:6200 --添加配置
racgons remove_config dbs:6200 dbp:6200 --刪除配置
ONS進程運行，並不代表ONS正常工作，需要使用ping命令來確認。比如ps -ef|grep ons可以看到ONS進程正常運行，但onsctl ping看到ons is not running...,啟動ONS服務：onsctl start 再次確認ONS服務狀態，已經ok。 $onsctl debug --查看詳細信息。
srvctl --RAC維護中最常用的命令，也是最復雜的命令。
查看配置：
$srvctl config database --顯示在OCR中注冊的所有數據庫
$srvctl config database -d a --查看數據庫a的配置
$srvctl config database -d a -a --查看數據庫a更詳細的配置
$srvctl config nodeapps -n dbs --返回節點名、實例、$ORACLE_HOME
$srvctl config nodeapps -n dbs -a --查看VIP配置
$srvctl config nodeapps -n dbs -g --查看GSD
$srvctl config nodeapps -n dbs -s --查看ONS
$srvctl config nodeapps -n dbs -l --查看listener
$srvctl config listener -n dbs --查看監聽器的名稱
$srvctl config asm -n dbp --查看ASM實例名和$ORACLE_HOME
$srvctl config service -d test -a --查看數據庫的所有service配置
$srvctl add database -d abc -o $ORACLE_HOME --添加數據庫
$srvctl add instance -d abc -n dbs -i abc2 --添加實例
$srvctl add service -d abc -s abcservice -r abc1 -a abc2 -P BASIC --添加服務
配置數據庫隨CRS的啟動而自動啟動：
srvctl enable/disable database -d test --啟動/關閉數據庫的自動啟動特性
srvctl config database -d test -a --確認配置是否成功
srvctl enable/disable instance -d test -i abc1 --開啟/關閉某個實例的自動啟動
srvctl disable service -d test -s abcservice -i abc1 --禁止服務在某個實例上運行
$srvctl remove service -d test -s abcservice --刪除service
$srvctl remove instance -d test -i abc1 --刪除abc1
$srvctl remove database -d test --刪除數據庫
remove命令刪除的只是對象在OCR中的定義信息，對象本身不會被刪除。
$srvctl start database -d test --啟動數據庫。
$srvctl start database -d test -i abc1 -o mount --啟動實例abc1到mount狀態。
$srvctl stop instance -d test -i abc1 -o immediate
$srvctl stop instance -d test -i abc1 -o abort
$srvctl start service -d test -s abcservice -i abc1
$srvctl status service -d test -v
跟蹤srvctl：10g中跟蹤srvctl，只需要設置SRVM_TRACE=true這個OS環境變量即可，這個命令的所有函數調用會輸出到屏幕上。
一個恢復案例（OCR磁盤和votedisk磁盤全部破壞，並且沒有備份）：
1.crsctl stop crs --停止所有節點的clusterware stack
2.$CRS_HOME/install/rootdelete.sh --分別在每個節點執行這個腳本。
3.$CRS_HOME/install/rootdeinstall.sh --只需要在一個節點上執行即可。
4.$CRS_HOME/root.sh --在和步驟3同一個節點執行這個腳本。
5.$CRS_HOME/root.sh --在其它節點執行這個腳本。
6.用netca命令重新配置監聽器，確認注冊到了clusterware中：crs_stat -t -v
7.srvctl add asm -n dbs -i +ASM1 -o /oracle/product/database
srvctl add asm -n dbp -i +ASM2 -o /oracle/product/database
8.srvctl start asm -n dbs
srvctl start asm -n dbp(這里出現了ORA-27550：的錯誤，這個問題是因為RAC無法確認使用哪個網卡作為private interconncect，所以可以通過在兩個ASM實例的pile中添加以下參數解決這個問題。
+ASM1.cluster_interconnects='10.0.0.8'
+ASM2.cluster_interconnects='10.0.0.9'
重啟ASM，問題得到解決)
9.srvctl add database -d test -o /oracle/product/database
10.srvctl add instance -d test -i abc1 -n dbs
srvctl add instance -d test -i abc2 -n dbp
11.srvctl modify instance -d test -i abc1 -s +ASM1 --修改實例和ASM實例的依賴關系
srvctl modify instance -d test -i abc2 -s +ASM2
12.srvctl start database -d test(啟動過程又出錯，跟ASM問題相同，解決辦法類似，修改database參數即可，如下：
SQL>alter system set cluster_interconnect='10.0.0.8' scope=spfile sid='abc1';
SQL>alter system set cluster_interconnect='10.0.0.9' scope=spfile sid='abc2';)
srvctl start database -d test --重啟數據庫，操作成功。
4.HA和LB
HA=MTTF/(MTTF+MTTR) MTTF=平均故障間隔時間 MTTR=平均修復時間
10g RAC failover的分類：client-side connect time failover;TAF;service-side TAF
注意：不要在listner.ora中設置GLOBAL_DB_NAME，這個參數會禁用connect_time failover和transparent application failover
client-side connect time failover:用戶端tnsname中配置了多個地址，用戶發起連接請求時，先嘗試第一個地址，如果連接失敗嘗試第二個地址，直到遍歷所有地址。它的特點是只在發起連接的時候才去感知節點故障，一旦連接建好后，節點故障不會處理，客戶端的表現就是會話斷開，用戶程序必須重新建立連接。在tnsnames.ora添加FAILOVER=ON條目即可實現此功能，系統默認就能實現這種功能。
TAF：如果某個實例發生故障，連接到這個實例上的用戶就會被自動遷移到其它的健康實例上。遷移對應用程序而言是透明的，但用戶未提交的事務會回滾。TAF的配置也很簡單，只要在tnsnames.ora添加FAILOVER_MODE配置項，這個條目有4個子項目需要定義。METHOD=BASIC/PRECONNECT (BASIC:感知節點故障時才創建到其它實例的連接。 PRECONNECT:在最初建立連接時就同時建立到所有實例的連接，這樣切換速度就快)。 TYPE=session/select(session:對於select語句切換后需要重新執行查詢語句。 select：對於select語句切換后在新的幾點繼續返回剩下的記錄。兩種方式對未提交的事務都自動回滾）。
DELAY和RETRIES表示重試間隔時間和重試次數。
service-side TAF：直接在服務器上修改配置，無需修改客戶端的tnsnames.ora文件。它通過結合service在數據庫里保存FAIL_MODE的配置，把所有的TAF配置保存在數據字典中，省去了客戶端的配置工作。
service-side TAF比TAF多出了一個instance role，所謂實例角色，就是有多個instance參與一個service時，可以配置優先使用哪個instance為用戶提供服務，用戶共有兩種可選角色：
PREFERRED:首選實例 AVAILABLE:后備實例。要想實現這個功能必須配置services（DBCA，手工方式（srvctl)都可以配置）。使用srvctl這個工具時，命令只更新OCR中的配置，不會更新數據字典和監聽器中的信息，因此還要用dbms_service包來更新數據字典。無論使用DBCA還是srvctl命令來配置service，都無法配置TAF的type、delay、retries3個屬性。必須使用dbms_services包來修改這些屬性。10g配置了service-side TAF，客戶端甚至都不需要tnsnames.ora文件。10g提供新連接方法：easy connect naming methods。連接串格式如下：username/password@[//]host[:port][/service_name]
oracle clusterware HA框架：這里強調的是oracle clusterware是一款獨立的集群件產品，不只是針對RAC，另外oracle也提供了API，用戶可以進行二次開發實現更豐富的功能。詳見書的P210。
LOADBALANCE:10g RAC提供兩種手段實現分散負載：純技術的分散負載;面向業務的的分散負載。
純技術的分散負載有兩種實現方法：客戶端均衡;服務器端均衡
客戶端均衡：oracle8實現的方法，使用隨機算法把連接請求分散到各個實例，這種分配方法沒有考慮每個節點的真實負載。
服務器端均衡：oracle9引進的方法。負載均衡的實現依賴於listener收集的負載信息，PMON進程會收集系統的負載信息，然后登記到listener中，最少1分鍾，最多10分鍾PMON要做一次更新，節點負載越高，更新頻率越高。如果listener關閉，PMON會每隔1秒鍾檢查listener是否重啟。除了自動定時更新任務外，用戶也可以使用alter system register命令手工進行這個過程。整個過程可以在listener日志看到。我們也可以使用1025事件跟蹤PMON進程，來查看注冊的內容。PMON不僅會向本地注冊，還可以向其它節點上的listener注冊，但到底向何處注冊，是由remote_listeners決定的，參數值是一個tnsnames項。
客戶端均衡和服務器端均衡不是互拆的，兩者可以一起工作。配置LB時有點需要注意：需要將各個實例的listener.ora文件中去掉缺省產生的sid_list_listener_name條目，這樣才能保證listener獲得的信息都是動態注冊的，而不是從文件中讀取的靜態信息。
利用service分散負載：通過把應用按照功能模塊進行划分成service，進而把每個service固定在某些RAC節點上。（cache fusion減少了）
5.備份
flash recovery area：閃回恢復區可以集中存放所有與恢復有關的文件，這些文件包括以下幾類：
控制文件（創建db時使用了閃回恢復區，會自動在這里創建一個控制文件的copy）
控制文件和spfile的自動備份
備份集backup set文件
image copy文件
歸檔日志，log_archive_dest_10會自動指向flash recovery area
閃回日志（閃回數據庫需要這種功能）
10g中的閃回功能家族中，只有閃回數據庫和閃回恢復區有關系（閃回日志必須放在閃回恢復區），其它的沒有直接關系。
10g中的v$logfile,v$control_file,v$datafile_copy,v$backup_piece,v$archived_log 這些視圖中也增加了
is_reconvery_dest_file列，代表該文件是否放在recovery area中。
RMAN>select name,is_recovery_dest_file from v$archived_log;
配置閃回區：RAC環境下的配置，要保證每個節點的配置值都相同。可以在線修改，立即生效：
SQL>alter system set db_recovery_file_dest='+DISKA' scope=both;
SQL>alter system set db_recovery_file_dest_size='5g' scope=both sid='*';
使用ASM作為閃回區，只能指定到diskgroup級別，而不能指定到目錄，ASM存儲管理是采用OMF方式，每個數據庫會被分配到指定目錄diskgroup/instance_name。
閃回區的監控：當空間使用率達到90%，會自動觸發刪除，如果沒有空間可以釋放，並且使用空間超過85%，會記錄一條warning日志，如果超過97%會記錄一條critical warning日志，這些日志內容可以從DBA_OUTSTANDING_ALERTS視圖查看。閃回區的使用情況可以通過v$recovery_file_dest來進行監控。
RMAN使用方法：
1.批處理方法：把命令寫入文本文件。cat back
run {
backup database;
}
通過cmdfile指定命令文件，使用log指定日志文件：
$rman target / cmdfile=back log=back.log
2.腳本方式：需要恢復目錄，腳本分local和global兩種。
local：連接到target db和catalog db
RMAN>create script full_bakcup
{
backup database plus archivelog
delete obsolete;
}
global：需要用global關鍵字
RMAN>create global script global_full_backup
{
backup database plus archivelog;
delete obsolete;
}
使用腳本： RMAN>run { execute script full_bakcup；}
備份格式：image copy只能在磁盤上進行，backup set是一種壓縮格式，RMAN能跳過空數據塊，備份的時候還可以額外壓縮，但image copy比backup set的restore速度快，盡管它占用較多的空間。
RMAN的備份保留策略： RMAN>configure retention policy to recovery window of 7 days;
RMAN>configure retention policy to redundancy 2;
RMAN>report obsolete;
RMAN>report obsolete recovery window of 7 days;
RMAN>report obsolete redundancy 2;
RMAN>show retention policy;
RMAN>delete obsolete;
RMAN>delete obsolete redundancy 2;
RMAN>delete obsolete recovery window of 4 days;
RMAN>configure retention policy to none;
RMAN只能對數據文件進行增量備份，控制文件、日志文件不能增量備份。增量備份能夠捕獲nologging操作的數據變化，而這些操作不會被記錄到日志上。
backup as copy db_file_name_convert=('+data/wxxrzxm','/backup/test') database; --路徑的轉變。
如果想把ASM上的數據文件備份到ASM上，上述方法可能會出錯，因為ASM是使用OMF方式管理數據文件的。
增量備份：oracle10g只允許0和1兩級了，0級相當於全備，但不能作為0級使用。
種類：RMAN>backup incremental level 1 database; --差異增量
RMAN>backup incremental level 1 cumulative database; --累加增量
舉個例子：
RMAN>run {
backup as copy db_file_name_convert=('+DATA/wxxrzm','/backup/test') incremental level 0 database tag 'full_backup';
}
RMAN>run {
backup incremental level 1 CUMULATIVE for recover of copy with tag 'full_backup' database;
recover copy of database with tag 'full_backup';
}
增量備份為了獲得要備份的數據塊，必須對數據文件中的所有數據塊進行遍歷，效率不高。因此oracle提供了一個特殊的文件叫block change tracking file，每當數據塊發生變化時，相關信息同時記錄到這個文件中。
SQL>alter database enable/disable block change tracking; --啟用關閉該功能。
SQL>select * from v$block_change_tracking; --查看文件的位置。
SQL>alter database enable block change tracking using file 'path' --手工指定文件位置。
啟用這個特征后oracle會啟動一個ctwr進程，它負責跟蹤數據變化。
RMAN>backup duration 2:00 database; --希望在2小時內完成備份，如果無法完成，整個任務都會出錯返回，產生的備份文件也不可用。
RMAN>backup duration 2:00 partial database filesperset 1; --保證產生的每個備份文件都對應一個數據文件。完成的備份保留。
RMAN>backup duration 0:01 minimize load database;
RMAN>backup duration 0:01 minimize time database;
恢復命令：10G，restore命令增加了一個preview子命令。舉例如下：
$rman / target
RMAN>spool log to test.log
RMAN>restore datafile 1 preview;
RMAN>restore database preview summary;
RMAN>spool log off;
RMAN>list backup;
RMAN>list copy;
RMAN>crosscheck copy;
RMAN>delete expired copy; --list顯示的信息是從控制文件獲得，如果用rm命令刪除copy這個動作不會同步到控制文件，這會造成不一致。
v$rman_output:查看每個備份任務的日志。 v$rman_status：查看備份任務的完成情況。
RAC的備份：RAC的備份與單實例備份有兩點需要注意：1.RMAN連接集群中的某個實例即可。 2.備份歸檔時，必須保證在備份實例上能夠訪問所有實例的歸檔日志，否則會報錯。
SQL>alter system set log_archive_dest_state_2=defer scope=both sid='*';
注意10g里增加的新參數log_archive_local_first參數，10g以前本地和遠程的歸檔都完成后，聯機日志文件才能被重用。這個參數設置為true后，oracle先進行本地歸檔，然后同時遠程傳遞和使用聯機日志。
6.恢復
修改數據塊之前，代表本次修改操作的redo記錄必須先要被保存下來，然后才能修改數據記錄。舊的日志被覆蓋前需要完成兩件事：1，檢查點必須完成。2，完成歸檔。
SCN的種類：系統檢查點SCN--記錄在控制文件中（v$database可以看到）。 數據文件檢查點SCN--記錄在控制文件中（v$datafile)。 數據文件的啟動、終止SCN--數據文件頭記錄啟動scn（v$datafile_header)，控制文件記錄數據文件的終止scn。這兩個SCN用來確認數據文件是否需要恢復。數據庫運行中，所有數據文件的終止SCN都是null，正常關閉數據庫后數據文件的終止scn會被設置成啟動scn，異常關閉數據庫后，終止scn來不及修改還是null。
每個實例對應的聯機日志就是一個redo thread。rac環境下每個實例都需要自己的聯機日志，也就是每個實例都有自己的redo thread，所以在rac下添加日志時必須指定線程號：
SQL>alter database add logfile thread 1 group 5('/oracle/oradata/redo5') size 50m;
日志切換觸發檢查點，檢查點啟動DBWR把data buffer cache中的dirty block寫入磁盤，當該聯機日志所覆蓋的操作都被同步到數據時，這個聯機日志文件就可以被重用了。但是dirty blcok在磁盤上不是連續分布的，所以日志切換要等待DBWR寫完，這就會導致用戶進程必須長時間的等待。oracle 8開始出現了增量檢查點的算法。執行檢查點時，只在控制文件中記錄當時的檢查點SCN，然后DBWR在后台進程進行寫操作，每隔3s，DBWR會在控制文件中更新checkpoint progress record，代表工作進展情況，而用戶進程繼續前台操作，不受DBWR的影響。
記住RAC下的聯機日志必須放在共享存儲上，因為恢復時必須把所有實例的聯機日志都合並，把redo log record按照SCN排序。
crash recovery：RAC下某個實例發生了crash后在其它實例上進行的recovery。在執行crash recovery時，故障節點被IO fencing，即故障節點不能對共享數據進行操作。
PCM-lock：用來描述數據塊的buffer copy在不同實例間的分布情況。它有三個屬性：MODE,ROLE,PAST IMAGE。具體參見書的P270。可以根據其它節點上的PCM-lock推斷出哪些數據塊需要恢復。關於crash recovery的過程詳見p273。
online block recovery：某個用戶進程修改數據時異常死掉，導致data buffer數據不一致，這時就會觸發online block recovery動作。這個動作找到一個恢復起點（最近的past image）應用聯機日志進行恢復。
完全恢復的一個特殊案例：數據結構改變后的恢復
先做一個全備份，然后添加一個數據文件，並創建一個表空間，同時增加一些數據。--》關閉數據庫，模擬災難。刪除剛才新建的數據文件。--》啟動數據庫，因為刪除的數據文件沒有備份，所以restore，recover的方法都不行。 --》只能用alter database create datafile重建數據文件（無需指定數據文件所屬的表空間，也不用指定數據文件大小，因為這些屬性在控制文件都有記錄） --》在ASM里要注意，你指定建的數據文件名可能跟控制文件記錄的數據文件名不同。這時需要將控制文件記錄的數據文件名rename成ASM里記錄的數據文件名。SQL>alter database rename file '' to '' -->再次recover datafile就可以了。
ASM也可以像目錄一樣操作：
$export ORACLE_SID=+ASM1
$asmcmd -p
ASMCMD[+] >cd +DATA2/DB/controlfile/
>ls
>rm ...
不完全恢復的一個案例：
1.RMAN>backup database; --先做一個全備份。
2.abort數據庫，進ASM刪除數據文件、聯機日志、控制文件。
3.SQL>startup nomount;
4.RMAN>restore controlfile from '自動備份‘
5.RMAN>sql 'alter database mount';
6.RMAN>restore database; --恢復過程中，數據文件被自動改名，並且改動被同步到控制文件中。
7.確定恢復終點。控制文件記錄的歸檔文件（v$archived_log)和磁盤上的歸檔文件數量不一樣，有4個文件時備份之后產生的。
8.RMAN>catalog archivelog '歸檔’; --將備份后產生的歸檔登記到控制文件。
9.SQL>recover database using backup controlfile until cancel; --執行不完全恢復。如果使用RMAN工具，需要使用set until提前指定恢復終點：
RMAN>run {
set until sequence 64 thread 2;
restore database;
recover database;
}
10.RMAN>sql 'alter database open resetlogs';
11.$srvctl start database -d test --打開其它實例。