Oracle學習之DATAGUARD(一) DG架構

    DataGuard運行原理非常簡單：傳輸日志、應用日志。下圖表示了DG的基本架構

1. 日志傳輸服務將主庫產生的日志數據傳到從庫。

2. 應用服務（Apply Service）驗證日志數據，并且更新從庫的數據文件。

3. 主數據庫的寫進程更新數據文件，并不依賴于DataGuard架構。

4. 當網絡或者從庫故障恢復時，DG自動重傳已經被主庫歸檔的日志數據。

• 日志傳輸服務Redo Transport Services

         Redo Transport Services協調主從庫之間的日志傳輸。當主庫LGWR寫日志時，Log Network Server (LNS)程序從Log buffer cache中讀取日志數據，通過Oracle Net Services將數據傳輸到從庫上。從庫上的Remote File Server (RFS)接收傳過來的日志。RFS將接收到的日志寫到standby redo log file (SRL).在多從庫環境下，主庫為每個從庫都啟用一個獨立的LNS進程，用來傳輸日志數據。

         使用LNS進程，DataGuard支持兩種日志傳輸方式：同步、異步。

         同步日志傳輸Synchronous Redo Transport

         Synchronous transport (SYNC) 也被稱為"零數據丟失"。只有當LNS確認日志被傳輸到從庫并且已經寫入磁盤后，主庫上的commit操作才會被認為成功。

Data Guard 日志傳輸進程架構

SYNC redo transport architecture

1. 用戶commit一個事務，將在Redo Buffer中生成一些redo record 。LGWR從Log buffer中讀取redo record并將其寫入Online Redo Logs,于此同時等待LNS進程的確認。

2.  LNS從Redo Buffer中讀取相同的redo record，通過ONS將其傳輸到從庫。RFS接收日志，將其寫入Standby Redo Logs。

3. 當RFS寫日志成功后，傳輸一個確認信號給主庫上的LNS，LNS將此確認信息告知LGWR。此時LGWR才能反饋給用戶提交成功的信息。 

Asynchronous transport (ASYNC)

  日志異步傳輸，LGWR無需等待LNS的確認信息。這種情況，standby幾乎對主庫沒有任何的性能影響。如果LNS傳輸日志的速度跟不上LGWR寫，當Log buffer被回收后，LNS就從online redo file從讀取日志傳輸到從庫。一旦LNS的速度跟上了，又會從Log buffer中讀取數據。

  有一種情況，假設LNS正在讀的current log的編號為10，再讀的過程中發生了兩次日志切換。現在current log編號變成了12. 這個時候LNS讀完了10. 它不會接著去讀取11號日志。而是直接切換到當前日志，編號為12的。 這種情況，11號日志沒有被LNS傳到standby 數據庫. 我們稱之為log file gap

當發生log file gap時，被歸檔的日志文件由arch進程負責傳輸到從數據庫。