一個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=<minutes>設置延遲時間，默認情況是沒有延遲時間的，若指定了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.至少有一個備庫處於可用狀態