一、名詞：
RFS（remote file server）：這個進程負責接收網絡上傳來的redo日誌，並把這些日誌寫到standby redo log文件中。
ARCH：同樣是歸檔進程，只是在備庫上，需要歸檔的是standby redo log文件的內容。
MRP（magaged recovery process）：這個進程負責協調介質恢復管理工作，整個物理備庫就是建立在介質恢復技術上的。
LSP（logical standby process）：這個進程在logical standby中才有，功能和物理備庫的MRP進程類似，負責協調SQL APPLY過程。
standby redo log（SRL）：Data Guard在備庫中，建議配置一種額外的日誌文件。叫做standby redo log（SRL），和傳統的online redo log（ORL）相比，SRL有着特殊的要求和作用。
online redo log（ORL）：
fetch archive log(FAL) :
FAL_SERVER :指定一個Oracle Net service name,standby數據庫使用這個參數連接到FAL server,這個參數適用於standby站點。比如,FAL_SERVER = PrimaryDB,此處PrimaryDB是一個TNS name,指向primary庫。
FAL_CLIENT:指定一個FAL客戶端的名字，以便FAL Server可以引用standby庫，這也是一個TNS name，primary庫必須適當配置此TNS name指向stanby庫。這個參數也是在standby庫端設置。比如，FAL_CLIENT = StandbyDB,StandbyDB是standby庫的TNS name。
GAP:當備庫不能接受到一個或多個主庫的歸檔日誌文件時候，就發生了archive gap。丟失的歸檔日誌文件就是gap，如果有gap，如果發生gap，dg會自動檢測和處理通過拷貝丟失的日誌到備庫。
二、架構
- standby redo log（SRL）：
-〉Data Guard在備庫中，建議配置一種額外的日誌文件，叫做standby redo log（SRL），和傳統的online redo log（ORL）相比，SRL有着特殊的要求和作用。兩者的關係可以從下面的幾點來對比：
（1）.SRL和ORL兩種文件是完全相同的，只是兩者發揮的作用和場景不同。
（2）.SRL只在備庫上起作用，（雖然主庫也可以配置SRL），但是當數據庫處於主庫角色的時候，SRL是不活動的，只有經過了角色切換，變成了備庫角色時，SRL日誌纔會變成活動的。
（3）.對於處於備庫角色的數據庫來說，ORL不是必須的，也不會起作用，（在很多時候，備庫雖然顯示有ORL，但是並沒有真正的操作系統文件存在，只有當角色切換，變成主庫角色時，才真正在操作系統上創建ORL文件）！
（4）.對於處於備庫角色的數據庫來說，他從主庫接收到的日誌可以記錄在SRL文件中，也可以記錄在歸檔日誌文件中，具體寫在哪個文件中取決於具體配置，但是不會寫在ORL中。
（5）.SRL必須和ORL大小完全一致，否則SRL也不會被用到。其次，從數量上，應該按照每個實例或日誌線程N+1的數量關係來配置，例如2個實例的RAC，如果每個實例3組日誌，則SRL應該是（3+1）*2=8組。
-〉 是否使用SRL，關鍵區別在於RFS把接收到的日誌，是寫在歸檔日誌裏，還是寫在SRL裏。
使用SRL可以帶來2大好處：
（1).性能
如果不使用SRL，則備庫的RFS會把接收到的日誌記錄到歸檔日誌文件中，每當主庫做日誌切換時，纔會觸發備庫對當前歸檔日誌的歸檔操作，因此他必須等待備庫的RFS進程創建並且初始化下一個歸檔日誌文件，用來容納以後傳遞的REDO內容。因此這個過程會影響主庫日誌的切換進度，當然對於異步傳送來說不影響主庫性能，但是仍然會導致備庫日誌落後的情況。
然而使用了SRL，因爲SRL預先建好，因此日誌切換時，無需額外的文件初始化工作，因此性能要更好一些。
（2）.支持Real-Time Apply（RTA）
前面介紹了實時同步，備庫最後一個日誌總是IN-MEMORY狀態。 - FAL_CLIENT和FAL_SERVER
FAL_CLIENT和FAL_SERVER是配置dataguard用到的兩個參數,FAL指獲取歸檔日誌(Fetch Archived Log)
在一定的條件下，或者因爲網絡失敗，或者因爲資源緊張，會在primary和standby之間產生裂隙，也就是有些歸檔日誌沒有及時的傳輸並應用到standby庫。因爲MRP(managed recovery process)/LSP(logical standby process)沒有與primary直接通訊的能力來獲取丟失的歸檔日誌。因此這些gaps通過FAL客戶和服務器來解決，由初始化參數定義FAL_CLIENT和FAL_SERVER。
FAL_SERVER指定一個Oracle Net service name,standby數據庫使用這個參數連接到FAL server,這個參數適用於standby站點。比如,FAL_SERVER = PrimaryDB,此處PrimaryDB是一個TNS name,指向primary庫。
FAL_CLIENT指定一個FAL客戶端的名字，以便FAL Server可以引用standby庫，這也是一個TNS name，primary庫必須適當配置此TNS name指向stanby庫。這個參數也是在standby庫端設置。比如，FAL_CLIENT = StandbyDB,StandbyDB是standby庫的TNS name。
FAL_CLIENT和FAL_SERVER應該成對設置或改變。
這兩個參數只需在standby庫設置，但也可以在primary庫設置這兩個參數，以方便switchover或failover時primary庫轉變爲standby角色。 - gap及處理
當備庫不能接受到一個或多個主庫的歸檔日誌文件時候，就發生了archive gap。丟失的歸檔日誌文件就是gap，如果有gap，如果發生gap，dg會自動檢測和處理通過拷貝丟失的日誌到備庫。
(1).gap什麼時候被發現
當主庫在本地歸檔一個日誌，但是備庫沒有收到，每分鐘，主庫就會看下他的備庫是否在規定日誌文件序號上有gap。
(2).gap怎麼被解決
gap 恢復通過投票機制處理，對物理和邏輯備庫，dg檢查gap及通過在主庫上面獲取丟失的redo日誌文件來解決。
自動gap恢復依賴主庫的可用性，如果主庫不可樣，你配置了多個物理備庫，那麼你可以配置額外的參數，這樣redo apply就可以在別的備庫上來解決gap。
三、模式
數據保護模式是指備庫和主庫之間數據同步程度。
Data Guard允許定義3種數據庫保護模式，分別是最大保護、最大可用、最大性能模式。
這3種模式的區別在於，當主庫發生故障時，備庫的數據會和主庫有多大的差距。