[讀書筆記]ORACLE11GR2 DataGuard架構

一、Data Guard架構圖

圖1.1 Data Guard 架構圖

Data Guard（以下簡稱DG）由5個部分組成，分別是重做數據服務、角色管理與切換、備庫的應用服務、主庫的保護模式、DG的管理。

二、重做傳輸服務

2.1 重做傳輸服務介紹

DG重做傳輸服務協調從主庫到備庫的重做數據傳輸過程。同時，主庫中的LGWR將重做數據寫入到自己聯機重做日志文件中（ORL）；LNS進程將主庫的SGA的緩沖的重做日志傳輸到備庫中；備庫上的RFS接收LNS傳輸的數據，將交由LGWR寫入到備用重做日志（SRL）中。

注：

1.ORL：Online Redo Logfile:連接重做日志文件；

2.LNS：Log Network Server:負責將主庫SGA中的重做緩沖數據傳輸到備庫中；

3.RFS：Remote File Server:負責接收LNS傳輸的數據。

4.SRL：Standby Redo Logfile:備用重做日志文件。

2.2 重做傳輸服務架構

圖2.1 重做傳輸服務

DG支持兩種LNS進程的傳輸方法：同步方法（SYNC）、異步方法（ASYNC）。

同步傳輸要等到LNS確認事務恢復所需的重做數據已被寫入到備用站點的磁盤上，才允許LGWR認可提交操作成功。這種方式能保護所有的數據都不會丟失，但是有可能會影響到主庫的性能。

異步傳輸中，LGWR不必等待來自LNS的確認消息，幾乎不會影響主庫的性能。異步傳輸中，還可以啟用重做數據壓縮的功能。

2.3 自動間隔處理

圖2.2 自動間隔處理

當LNS進程停止將重做數據傳輸到備庫時而主庫卻繼續提交事務時，會出現日志間隔。在中斷期間，主庫上使用特殊的ARCH進程連續ping備庫來確定其狀態。當還原與備庫的通信后，ARCH ping進程會通過RFS進程查詢備用控制文件來確定備庫從主庫收到的最后一個完整日志文件，確定需要哪些日志文件來重新同步備庫，并通過其他的ARCH進程傳輸相應的日志文件。

在接下來執行日志切換時，LNS會試圖連接備庫，成功后開始傳輸當前的重做數據，而ARCH在后臺處理間隔。備庫上的應用歸檔日志的速度趕上重做記錄之后，應用進程不再讀取歸檔日志，改而讀取當前的SRL（假定配置了“實時應用”）。

三、應用服務

Data Guard提供兩種不同方法在備用數據庫上應用重做數據分別是物理備用和邏輯備用。

物理備用是主庫逐塊對應的精確物理副本；邏輯備用使用邏輯進程將更改協調應用于備用數據庫。

注：目前只用過物理備用，邏輯備用沒有去接觸。

四、保護模式

DG的保護模式有三種：最高性能模式（默認）、最高可用模式、最大保護模式。

最高性能模式：重視主庫的性能，輕視數據保護，使用ASYNC重做傳輸。

最高可用模式：最強調可用性，其次強調零數據損失保護，使用SYNC重做傳輸。主庫未能從備庫收到確認消息，會斷開LNS連接，并在主庫上繼續提交事務。

  最大保護模式：將數據保護放在首位，使用SYNC重做傳輸。如果主庫接收不到可用備庫的確認消息，主庫會停止。

五、角色管理與角色轉換

DG中有主庫和備庫兩種角色，角色之間的切換有switchover 和 failover兩種。

六、DG的管理方式

DG的管理方式有三種，分別是SQL*PLUS、DG Broker和OEM。

參考資料：

  《Oracle Data Guard 11g完全參考手冊》 第一章。