oracle rac理解和用途擴展

時間 2019-11-08

標籤 oracle rac 理解用途擴展欄目 Oracle 简体版

原文原文鏈接

　　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的級別。心跳應該用獨立的網卡。css

　　固然，rac自己之保證了數據庫服務器的高可用和高性能，因此最好有其餘的存儲技術來保證存儲的高可用，例如raid\vplex等。node

　　在距離不太遠（幾十千米），且速度較快（例如裸光纖）下，延時較小，，米足夠多，能夠考慮使用oracle rac實現雙活或者災備，RTO RPO=0。linux

附：算法

1.rac基本理論知識sql

1.1 Public NIC接入公共網絡，private NIC接入私有網絡，這是個徹底隔離的網絡傳遞的數據只是RAC節點的心跳數據和cache fusion數據。oracle不建議私有網絡直接用交叉線鏈接。數據庫

1.2 RAC最重要的是共享存儲。數據文件、聯機日誌、控制文件、參數文件都必須放在共享存儲上。如今的存儲環境基本上都是基於SAN的，跑FC協議（FC協議封裝了SCSI協議）。windows

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兩種存儲方案。session

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主要是藉助兩種心跳機制來完成健康檢測：一、節點間的網絡心跳。二、控制文件的磁盤心跳。每一個節點的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環境下配置歸檔日誌有多種選擇：一、NFS。二、實例間歸檔。三、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，配置存儲的時候有兩點須要注意：一、保證LUN在各節點上的順序同樣。二、設備名對應的物理設備不會由於系統的重啓發生變化。好比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';