Oracle學(xué)習(xí)之DATAGUARD(一) DG架構(gòu)

    DataGuard運行原理非常簡單：傳輸日志、應(yīng)用日志。下圖表示了DG的基本架構(gòu)

1. 日志傳輸服務(wù)將主庫產(chǎn)生的日志數(shù)據(jù)傳到從庫。

2. 應(yīng)用服務(wù)（Apply Service）驗證日志數(shù)據(jù)，并且更新從庫的數(shù)據(jù)文件。

3. 主數(shù)據(jù)庫的寫進程更新數(shù)據(jù)文件，并不依賴于DataGuard架構(gòu)。

4. 當網(wǎng)絡(luò)或者從庫故障恢復(fù)時，DG自動重傳已經(jīng)被主庫歸檔的日志數(shù)據(jù)。

• 日志傳輸服務(wù)Redo Transport Services

         Redo Transport Services協(xié)調(diào)主從庫之間的日志傳輸。當主庫LGWR寫日志時，Log Network Server (LNS)程序從Log buffer cache中讀取日志數(shù)據(jù)，通過Oracle Net Services將數(shù)據(jù)傳輸?shù)綇膸焐稀膸焐系腞emote File Server (RFS)接收傳過來的日志。RFS將接收到的日志寫到standby redo log file (SRL).在多從庫環(huán)境下，主庫為每個從庫都啟用一個獨立的LNS進程，用來傳輸日志數(shù)據(jù)。

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

         同步日志傳輸Synchronous Redo Transport

         Synchronous transport (SYNC) 也被稱為"零數(shù)據(jù)丟失"。只有當LNS確認日志被傳輸?shù)綇膸觳⑶乙呀?jīng)寫入磁盤后，主庫上的commit操作才會被認為成功。

Data Guard 日志傳輸進程架構(gòu)

SYNC redo transport architecture

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

2.  LNS從Redo Buffer中讀取相同的redo record，通過ONS將其傳輸?shù)綇膸臁FS接收日志，將其寫入Standby Redo Logs。

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

Asynchronous transport (ASYNC)

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

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

當發(fā)生log file gap時，被歸檔的日志文件由arch進程負責傳輸?shù)綇臄?shù)據(jù)庫。