1.概述
data guard
支援兩種使用
lns（
log network server
）程序的重做傳輸方法：同步（
sync
）和非同步（
async）。
傳輸程序架構：
2.同步傳輸
同步傳輸（
synchronous transport
，sync)
，又稱「零資料損失」方法，因為要等到
lns確認事務恢復所需的重做資料已被寫入到備用庫的磁碟上，才允許
lgwr
確認提交成功。如圖：
（1）當使用者發出 commit命令後，將產生一條 redo record （也稱作redo entry）放入sga中的 redo buffer 中，後台程序lgwr將讀取此redo record，將其寫入online redo log file，然後等待從lns程序傳來的確認資訊。 （
2）lns程序同樣從redo log buffer讀取redo record，並將其通過oracle net services傳輸給standby db。在standby db上的rfs後台程序將接收到的redorecord寫入standby
logfile中。
（3）當rfs確定寫入所有的redo record到磁碟後，向primarydb的lns傳送確認資訊。當lgwr收到lns**的確認資訊後，才返回commit成功的訊息給使用者。
3.非同步傳輸
非同步傳輸（
asynchronous transport,async
）與sync
的不同之處在於，
lgwr
不必等待來自
lns的確認訊息，而且 data guard 11g lns直接讀取redo buffer中的redo record。如果lns趕不上進度
，lns
程序會平滑切換到從主資料庫的
orl讀取和傳送（在
11g版本內增強了這一功能）。
4.自動間隔偵測 當
lns程序停止將重做資料傳輸到備用資料庫，而主資料庫卻就繼續提交事務時，就會出現日誌檔案間隔，另外網路失效時也可能產生這種情況。在此狀態下，主資料庫
lgwr
程序繼續寫入到當前
orl，填滿
orl後，會切換到下一組
orl，此時歸檔程序會在本地歸檔已滿的
orl，這在繁忙的系統會出現很大的日誌間隔。
在中斷期間
,data guard
在主資料庫上使用
arch
程序連續
ping
備用資料庫來確定其狀態。當還原與備用資料庫的通訊後，
arch ping
進行會查詢備用控制檔案（通過其
rfs程序），來確定備用資料庫從主資料庫收到的最後乙個完整日誌檔案。
data guard
確定需要哪些日誌檔案來重新同步備用資料庫，然後立即開始使用其他
arch
程序傳輸相應檔案。在接下來執行日誌切換時，
lns會試圖連線備用資料庫，成功後開始傳輸當前的重做資料，而
arch
程序在後台處理間隔。上圖的虛線表示傳輸和應用所需的重做來處理日誌檔案間隔。一旦備用應用程序能趕上當前重做記錄的進度，應用程序就自動切換，不再讀取歸檔重做日誌，改而讀取當前的
srl(
若配置了
data guard). 從
data guard 10g
開始，主資料庫的乙個
arch
程序一直專門負責本地歸檔，從而確保在處理間隔期間，遠端歸檔操作不影響主資料庫的歸檔操作。
在主備資料庫之間處於非同步狀態的時間越久，故障發生時損失資料的風險越大。
data guard
執行時使用多個後台
arch
程序來快速處理間隔，與此同時，
lns程序像往常一樣執行當前日誌流的
sync
和async
傳輸。
dataguard傳輸日誌方式
日誌傳送 redo send 日誌接收 redo receive primary database產生的redo日誌需要傳送到standby database。傳送動作由primary database的lgwr或者arch程序完成。不同的歸檔目的地可以使用不同的程序 但同一目的地只能選用一種程序。...
Dataguard中日誌傳輸服務
之前，原本已經嘗試過配置oracle例項的邏輯和物理standby結構，並且做個一些role交換操作，可是由於昨天學習rman的部分命令時沒留意，誤刪掉了primary db上的所有歸檔日誌，因為原來是在maximum protection模式下，standby db上還存在archivel gap...
Dataguard之redo傳輸服務
整個data guard體系就是圍繞三個關鍵點展開 日誌傳送 redo send 日誌接收 redo receive primary database產生的redo日誌需要傳送到standby database。傳送動作由primary database的lgwr或者arch程序完成。不同的歸檔目的...