一個Data Guard 配置由一個生產庫和一個或者多個standby數據庫組成，在Data Guard配置中，主庫和備庫都既可以是rac環境，也可以是單機環境。

這篇文章主要介紹dataguard的一些基本知識

dataguard的分類、dataguard的服務類型、dataguard的保護模式

1.Dataguard中的備庫分為物理備庫和邏輯備庫及快照備庫

備庫是主庫的一致性拷貝，使用一個主庫的備份可以創建多到30個備庫，將其加入到dataguard環境中，創建成功后，dataguard通過自動應用從主庫傳送到備庫的redo數據維護每個備庫。

1.1物理備庫(Physical standby database)

物理備庫提供物理上和主數據庫相同的拷貝，磁盤數據庫結構和主庫是相同的，物理備庫是塊到塊的拷貝，一個物理備庫通過應用從主庫收到的redo數據保持和主庫的同步，稱為日志應用(redo apply),11g的dataguard在應用日志的時候是可以打開的，10g是不允許的。11g的這種特性稱為active data guard。

1.2邏輯備庫 (Logical standby database)

邏輯備庫包含和主庫相同的邏輯信息，物理結構和數據結構可以是不同的，邏輯備庫把從主庫收到的redo轉換為sql語句，然后在備庫上執行sql語句，稱為sql應用(sql apply)。邏輯備庫除了能應用于災難恢復，還允許用戶查詢邏輯備庫和通過邏輯備庫生成報表，用于其他目的，使用邏輯備庫能升級database軟件，在無停機的情況下打補丁等操作。

1.3快照備庫 (Snapshot Standby Database)

快照備庫是11g中出現的，類似物理備庫和邏輯備庫一樣，快照備庫從主庫接收redo數據，和物理或邏輯備庫不同的是，快照備庫只接收而不應用接收到的redo數據。直至快照備庫轉換為物理備庫，之后先扔掉任何對快照備庫的更新，然后應用接收到的redo數據。快照數據庫最好用在要求臨時的，可更新的物理備庫快照場景。

典型的data guard配置如圖所示，來自oracle concept

2. dataguard的服務類型 (Data GuardServices)

日志傳輸服務(Redo Transport Services)

日志應用服務(Apply Services)

角色轉換 ? ? (Role Transitions)

2.1日志傳送服務管理從生產庫傳送redo數據到一個或多個歸檔目錄。日志傳輸服務完成以下工作：

2.1.1在配置中從主庫傳輸redo數據到備庫

2.1.2在網絡失敗后，管理備庫缺失的archivelog，自動解決缺失

2.1.3自動掃描在備庫中錯誤的或損壞的redo，自動從主庫或其他備庫重新獲得并替換損壞的archive log。

log_archive_dest_n初始化參數用來確定本地的redo和遠程歸檔redo的位置。log_archive_dest_n中詳細參數解析

2.2日志應用服務在備庫中應用redo數據，維護和備庫主庫之間的同步，redo數據默認從歸檔redo日志中應用，若啟用了實時應用，則直接從standby redo日志中應用；對于非實時應用redo，當主庫日志發生切換時，備庫才會應用從主庫傳輸來的redo日志。默認情況下，對于非實時應用，應用服務會等待備庫redo日志被歸檔才會應用歸檔redo日志，實時應用允許應用服務應用當前正在填充的備庫redo日志中的redo數據。

日志應用工作方式：redo apply和sql apply

物理備庫和邏輯備庫主要的區別就是日志應用的工作方式不同，物理備庫使用redo apply，邏輯備庫使用sql apply，類似MySQL 的主從的方式。

Redo apply在物理備庫上使用常規的數據庫恢復技術，也就是介質恢復，來應用redo中的數據。如圖所示：

Sql apply在邏輯備庫上使用這種方式，首先將接收到的redo數據轉換為sql語句，然后在邏輯備庫中執行生成的sql語句，之后在備庫中應用。使用的是logminer技術。如圖

日志應用服務配置

standby redolog

實時應用要求standby數據庫必須有standby redo日志，lgwr同步和異步傳輸模式要求傳輸目的地配置standby redo日志，standby redo日志用于存儲從一個主庫接收到的redo日志，standby redo日志在結構上和聯機redo日志是相同的，也使用創建和管理聯機redo日志相同的sql來創建和管理standbyredo日志。

Standby數據庫使用RFS前臺進程接收傳送過來的redo日志，將其寫到當前的standby redo日志組，當源數據庫發生了日志切換，傳入的redo將寫到下一個standby redo日志組中，之前的standby 日志通過ARCn前臺進程被歸檔。在源數據庫，進程順序地填充和歸檔redo日志組，這種方式唄鏡像到每個redo傳輸目的地，在standby數據庫以相同的順序填充和歸檔standby redo日志組。

每個standby redo日志的大小必須至少和redo源數據庫的redo日志組中最大的redo日志一樣大，推薦傳輸目的地的standby redo日志和源主庫的redo日志中的所有日志相同大。

對于standby 數據庫的每個redo線程，standby redo日志至少比在redo源主庫的redo日志多一個redo日志組，在源主庫，查詢v$log視圖確定源主庫redo日志組的個數，對于rac，查詢v$thread視圖確定源主庫redo的線程數，對每個線程使用的standby redo日志進行配置。

操作過程：

selectgroup#,bytes from v$Log ;主庫

selectgroup#,bytes from v$standby_log ;備庫

Oracle推薦在dataguard中的主數據庫也創建standby redo日志，這樣當switchover到備庫角色也可以立即實現實時接收redo數據

alterdatabase add standby logfile創建或添加standby redo日志，如果standby redo日志租不活動或者redo傳輸用于解決缺失，那么standby數據庫接收到的redo數據被直接寫到一個歸檔redo日志。

實時應用redo 數據

若啟用實時應用特性，應用服務能在不等待當前standby redo數據被歸檔的情況下，應用接收到的redo數據，這樣使得switchover和failover的速度更快，因為standby redo日志中的數據在failover或者switchover開始的時候已經被應用到standby 數據庫，減少了切換需要花費的時間。

物理備庫開啟實時引用

alterdatabase recover managed standby database using curren logfile dixconnect fromsession ;

邏輯備庫開啟實時引用

alterdatabase start logical standby apply immediate ;

啟用實時應用要求備庫配置由standby redo日志，并且開啟了歸檔

注:對于日志傳輸，可以將其劃分為實時傳輸(同步、異步)和切換時傳輸(默認傳輸方式)，實時傳輸與實時應用之間沒有關系，實時傳輸只是和dataguard保護模式有關。

延遲應用redo

在一定程度上保護應用程序對主庫的破壞及減少誤操作對standby數據庫的影響。當設置delay間隔之后，不能延遲傳輸redo數據到standby數據庫，只是會延遲應用redo日志，從standby目的地完成歸檔開始計算延遲時間。延遲結束之后開始應用歸檔日志。

指定延遲時間：

在主庫和備庫通過指定log_archive_dest_n初始化參數delay=設置延遲時間，默認情況是沒有延遲時間的，若指定了delay參數但是沒有指定值，默認是30分鐘。

取消指定時間

物理備庫

alterdatabase recover managed standby database nodelay ;

邏輯備庫

alterdatabase start logical standby apply nodelay;

執行以上的命令，在時間間隔到之前應用服務立即開始應用歸檔redo日志文件到備庫。

2.3使用switch over或failover操作改變數據庫角色，將備庫轉換成主庫或將主庫轉換為備庫。

Switchover是主庫個一個備庫的轉換，可以確保沒有數據丟失，是在有計劃的典型操作。在switchover期間，主庫角色轉變為備庫，備庫轉換為主庫，在主庫inactive時，failover可以將備庫轉換為主庫角色，failover可能會導致數據丟失，failover只有在主數據庫啟動失敗的情況下才使用。

3.dataguard的保護模式

Oracle提供三種保護模式滿足不同級別的系統。最大保護、最大性能、最高可用。三種保護模式都要求使用特定的redo傳送選項發送redo數據到至少一個備庫

3.1最大保護

如果主庫失敗，最大保護模式可以確保沒有數據丟失，事務在完成提交之前，事務恢復需要的redo數據必須寫到主庫的聯機redo日志和至少一個同步的備庫的standby redo log，若主庫不能寫redo數據到至少一個備庫，為了確保數據不會丟失，主庫會被關閉，正是應了最大保護模式這句話。

使用最大保護模式必須符合的條件：

a.主庫在log_archive_dest_n的參數設置中必須使用到lgwr sync affirm屬性來歸檔到備庫

b.備庫必須配置standby redo log

c.至少有一個備庫是可用的

采用最大保護模式的主庫，不能使用shutdown immediate對唯一的standby數據庫執行關閉操作。因為會導致主庫關閉

3.2最大性能

是默認的保護模式，提供在不影響主庫性能的情況下的最高級別的數據庫保護模式，主庫的用戶事務一旦被寫入本地聯機redo中，就被允許提交，不需要立刻寫到至少一個備庫中，主庫只要使用arch 或lgwr async屬性對遠程的備庫進行歸檔即可，redo數據也寫到一個或多個備庫，但是對于事務提交是異步完成的，因此通過延遲寫redo數據到備庫不會影響主庫的性能，這種保護模式提供您比最高可用模式較少的保護，但是能最低程度的影響主庫的性能

3.3最高可用

采用個最大保護模式同樣的方式，確保redo日志被完全寫入本地數據庫和至少一個備庫的standby redo log中，才會給用于返回提交完成的信息，若因為某些原因導致備庫不可用，主庫不能講redo寫入到備庫的standby redo 中，此時主庫并不會關閉，主庫將暫時將保護模式降為最大性能模式，并且繼續進行工作，一旦備庫恢復正常，主庫的缺失消除方案會啟動，歸檔redo日志的缺失部分會被填滿，當主庫下一個日志打開的時候，主庫中的保護模式又會上升為最高可用。采用最高可用必須滿足的條件：

a.主庫在log_archive_dest_n初始化參數中需要使用lgwr sync affirm屬性歸檔到備庫

b.備庫必須配置standby redo log

c.至少有一個備庫處于可用狀態