Data Guard理論概述(原創)

Data Gurad概述

不少未實際接觸過dg的初學者可能會下意識以為data guard是一個備份恢複的工具。我要說的是，這種形容不完全錯，dg擁有備份的功能，某些情況下它甚至可以與primary資料庫完全一模一樣，但是它存在的目的并不僅僅是為了恢複資料，應該說它的存在是為了 確定企業資料的高可用性，資料保護以及災難恢複 ( 注意這個字眼，災難恢複) 。dg提供全面的服務包括：建立，維護，管理以及監控standby資料庫，確定資料安全，管理者可以通過将一些操作轉移到standby資料庫執行的方式改善資料庫性能 ，建構高可用的企業資料庫應用環境。

在Data Gurad 環境中，至少有兩個資料庫，一個處于Open 狀态對外提供服務，這個資料庫叫作Primary Database。 第二個處于恢複狀态，叫作Standby Database。 運作時primary Database 對外提供服務，使用者在Primary Database 上進行操作，操作被記錄在聯機日志和歸檔日志中，這些日志通過網絡傳遞給Standby Database。 這個日志會在Standby Database 上重演，進而實作Primary Database 和Standby Database 的資料同步。

Oracle Data Gurad 對這一過程進一步的優化設計，使得日志的傳遞，恢複工作更加自動化，智能化，并且提供一系列參數和指令簡化了DBA工作。

如果是可預見因素需要關閉Primary Database，比如軟硬體更新，可以把Standby Database 切換為Primary Database 繼續對外服務，這樣即減少了服務停止時間，并且資料不會丢失。如果異常原因導緻Primary Database 不可用，也可以把Standby Database 強制切換為Primary Database繼續對外服務，這時資料損失都和配置的資料保護級别有關系。是以Primary 和Standby 隻是一個角色概念，并不固定在某個資料庫中。

Data Guard 架構

DG架構可以按照功能分成3個部分：

1） 日志發送（Redo Send）

2） 日志接收（Redo Receive）

3） 日志應用（Redo Apply）

1. 日志發送（Redo Send）

Primary Database 運作過程中，會源源不斷地産生Redo 日志，這些日志需要發送到Standy Database。 這個發送動作可以由Primary Database 的LGWR 或者ARCH程序完成， 不同的歸檔目的地可以使用不同的方法，但是對于一個目的地，隻能選用一種方法。 選擇哪個程序對資料保護能力和系統可用性有很大差別。 

1.1 使用ARCH 程序

1）Primary Database 不斷産生Redo Log，這些日志被LGWR程序寫到聯機日志。

2）當一組聯機日志被寫滿後，會發生日志切換（Log Switch），并且會觸發本地歸檔，本地歸檔位置是采用 LOG_ARCHIVE_DEST_1='LOCATION=/path' 這種格式定義的。

如：alter system set log_archive_dest_1 = 'LOCATION=/u01/arch' scope=both;

3）完成本地歸檔後，聯機日志就可以被覆寫重用。

4）ARCH 程序通過Net 把歸檔日志發送給Standby Database的RFS（Remote File Server） 程序。

5）Standby Database 端的RFS 程序把接收的日志寫入到歸檔路徑中。

6）Standby Database 端的MRP(Managed Recovery Process)程序（Redo Apply）或者LSP 程序（SQL Apply）在Standby Database上應用這些日志，進而同步資料。

用ARCH模式傳輸不寫Standby Redologs，直接儲存成歸檔檔案存放于Standby端。

說明：

邏輯Standby接收後将其轉換成SQL語句，在Standby資料庫上LSP程序執行SQL語句實作同步，這種方式叫SQL Apply。

實體Standby接收完Primary資料庫生成的REDO資料後，MRP程序以媒體恢複的方式實作同步，這種方式也叫Redo Apply。

注意：建立邏輯Standby資料庫要先建立一個實體Standby資料庫，然後再将其轉換成邏輯Standby資料庫。

使用ARCH程序傳遞最大問題在于： Primary Database 隻有在發生歸檔時才會發送日志到Standby Database。 如果Primary Database 異常當機，聯機日志中的Redo内容就會丢失，是以使用ARCH 程序無法避免資料丢失的問題，要想避免資料丢失，就必須使用LGWR，而使用LGWR 又分SYNC（同步）和ASYNC（異步）兩種方式。

在預設方式下，Primary Database使用的是ARCH程序，參數設定如下：

alter system set log_archive_dest_2 = 'SERVICE=ST' scope=both;

1.2 使用LGWR 程序的SYNC 方式

1）Primary Database 産生的Redo日志要同時寫到日志檔案和網絡。也就是說LGWR程序把日志寫到本地日志檔案的同時還要發送給本地的LNSn程序（Network Server Process），再由LNSn（LGWR Network Server process）程序把日志通過網絡發送給遠端的目的地，每個遠端目的地對應一個LNS程序，多個LNS程序能夠并行工作。

2）LGWR 必須等待寫入本地日志檔案操作和通過LNSn程序的網絡傳送都成功，Primary Database上的事務才能送出，這也是SYNC的含義所在。

3）Standby Database的RFS程序把接收到的日志寫入到Standby Redo Log日志中。

4）Primary Database的日志切換也會觸發Standby Database 上的日志切換，即Standby Database 對Standby Redo Log的歸檔，然後觸發Standby Database 的MRP或者LSP程序恢複歸檔日志。

因為Primary Database 的Redo 是實時傳遞的，于是Standby Database 端可以使用兩種恢複方法：

實時恢複（Real-Time Apply）： 隻要RFS把日志寫入Standby Redo Log 就會立即進行恢複；

歸檔恢複： 在完成對Standby Redo Log 歸檔才觸發恢複。

Primary Database預設使用ARCH程序，如果使用LGWR程序必須明确指定。使用LGWR SYNC方式時，可以同時使用NET_TIMEOUT參數，這個參數機關是秒，代表如果多長時間内網絡發送沒有響應，LGWR 程序會抛出錯誤。 示例如下：

alter system set log_archive_dest_2 = 'SERVICE=ST  LGWR  SYNC  NET_TIMEOUT=30' scope=both;

1.3 使用LGWR程序的ASYNC 方式

使用LGWR SYNC方法的可能問題在于，如果日志發送給Standby Database過程失敗，LGWR程序就會報錯。也就是說Primary Database的LGWR 程序依賴于網絡狀況，有時這種要求可能過于苛刻，這時就可以使用LGWR ASYNC方式。 它的工作機制如下：

1） Primary Database 一段産生Redo日志後，LGWR 把日志同時送出給日志檔案和本地LNS 程序，但是LGWR程序隻需成功寫入日志檔案就可以，不必等待LNSn程序的網絡傳送成功。

2） LNSn程序異步地把日志内容發送到Standby Database。多個LNSn程序可以并發發送。

3） Primary Database的Online Redo Log 寫滿後發生Log Switch，觸發歸檔操作，也觸發Standby Database對Standby Database對Standby Redo Log 的歸檔；然後觸發MRP或者LSP 程序恢複歸檔日志。

因為LGWR程序不會等待LNSn程序的響應結果，是以配置LGWR ASYNC方式時不需要NET_TIMEOUT參數。示例如下：

alter system set log_archive_dest_2 = 'SERVICE=ST  LGWR  ASYNC ' scope=both;

2. 日志接收（Redo Receive）

Standby Database 的RFS（Remote File Server）程序接收到日志後，就把日志寫到Standby Redo Log或者Archived Log檔案中，具體寫入哪個檔案，取決于Primary 的日志傳送方式和Standby database的位置。如果寫到Standby Redo Log檔案中，則當Primary Database發生日志切換時，也會觸發Standby Database上的Standby Redo Log 的日志切換，并把這個Standby Redo Log 歸檔。 如果是寫到Archived Log，那麼這個動作本身也可以看作是個歸檔操作。

在日志接收中，需要注意的是歸檔日志會被放在什麼位置：

1） 如果配置了STANDBY_ARCHIVE_DEST參數，則使用該參數指定的目錄。

2） 如果某個LOG_ARCHIVE_DEST_n 參數明确定義了VALID_FOR=(STANDBY_LOGFILE,*)選項，則使用這個參數指定的目錄。

3） 如果資料庫的COMPATIBLE參數大于等于10.0，則選取任意一個LOG_ARCHIVE_DEST_n的值。

4） 如果STANDBY_ARCHIVE_DEST 和 LOG_ARCHIVE_DEST_n 參數都沒有配置，使用預設的STANDBY_ARCHIVE_DEST參數值，這個預設值是$ORACLE_HOME/dbs/arc.

3. 日志應用（Redo Apply）

日志應用服務，就是在Standby Database上重演Primary Database日志，進而實作兩個資料庫的資料同步。 根據Standby Database重演日志方式的不同，可分為實體Standby（Physical Standby）和邏輯Standby （Logical Standby）。

Physical Standby 使用的是Media Recovery 技術，在資料塊級别進行恢複，這種方式沒有資料類型的限制，可以保證兩個資料庫完全一緻。 Physical Standby資料庫隻能在Mount狀态下進行恢複，也可以是打開，但隻能已隻讀方式打開，并且打開時不能執行恢複操作，即在打開狀态下不能應用日志。

Logical Standby使用的是Logminer 技術，通過把日志内容還原成SQL 語句，然後SQL引擎執行這些語句，Logminer Standby不支援所有資料類型，可以在視圖DBA_LOGSTDBY_UNSUPPORTED 中檢視不支援的資料類型，如果使用了這種資料類型，則不能保證資料庫完全一緻。 Logical Standby資料庫可以在恢複的同時進行讀寫操作。

Standby資料庫的相關程序讀取接收到的REDO資料（可能來自于Standby端的歸檔檔案，也可能來自于Standby Redologs），再将其寫入Standby資料庫。儲存之後資料又是怎麼生成的呢？兩種方式：實體Standby通過REDO應用，邏輯Standby通過SQL應用

根據Redo Apply發生的時間可以分成兩種：

一種是實時應用（Real-Time Apply）， 這種方式必須Standby Redo Log，每當日志被寫入Standby Redo Log時，就會觸發恢複，使用這種方式的好處在與可以減少資料庫切換（Switchover 或者Failover）的時間，因為切換時間主要用在剩餘日志的恢複上。

另一種是歸檔時應用，這種方式在Primary Database發生日志切換，觸發Standby Database 歸檔操作，歸檔完成後觸發恢複。 這也是預設的恢複方式。

如果是Physical Standby，可以使用下面指令啟用Real-Time：

Alter database recover managed standby database using current logfile;

如果是Logical Standby，可以使用下面指令啟用Real-Time：

Alter database start logical standby apply immediate;

檢視是否使用Real-Time apply：

Select recovery_mode from v$archive_dest_status;

上文提到了實體Standby和邏輯Standby，下面我們來詳細介紹下這兩類standby資料庫。

實體Standby

我們知道實體Standby與Primary資料庫完全一模一樣，DG通過REDO應用來維護實體Standby資料庫。

通常在實體Standby沒有執行REDO應用操作的時候，可以将實體Standby資料庫以READ ONLY模式打開，如果資料庫中指定了Flashback Area的話，甚至還可以被臨時性的置為READ WRITE模式，操作完之後再通過Flashback Database特性恢複回READ WRITE前的狀态，以便繼續接收Primary端發送的REDO并應用。

實體Standby通過REDO應用來保持與Primary資料庫的一緻性，所謂的REDO應用，實質是通過Oracle的恢複機制，應用歸檔檔案（或Standby Redologs檔案）中的REDO資料。 恢複操作屬于塊對塊的應用 。如果正在執行REDO應用的操作，Oracle資料庫就不能被Open。

READ ONLY模式打開。以READ ONLY模式打開後，可以在Standby資料庫執行查詢或備份等操作（變相減輕Primary資料庫壓力）。此時Standby資料庫仍然能夠繼續接收Primary資料庫發送的REDO資料，不過并不會應用，直到Standby資料庫重新恢複REDO應用。

也就是說在READ ONLY模式下不能執行REDO應用，REDO應用時資料庫肯定處于未打開狀态。如果需要的話，你可以在兩種狀态間轉換，如先應用REDO，然後将資料庫置為READ ONLY狀态，需要與Primary同步時再次執行REDO應用指令，切換回REDO應用狀态.

說明： Oracle 11g版本中增強實體Standby的應用功能，在11g版本中，實體Standby可以在OPEN READ ONLY模式下繼續應用REDO資料，這就極大地提升了實體Standby資料庫的應用場合。

READ WRITE模式打開。如果以READ WRITE模式打開，那麼Standby資料庫将暫停從Primary資料庫接收REDO資料，并且暫時失去災難保護的功能。當然，以READ WRITE模式打開也并非一無是處，如你可能需要臨時調試一些資料，但又不友善在正式庫中操作，那就可以臨時将Standby資料庫置為READ WRITE模式，操作完之後将資料庫閃回到操作前的狀态（閃回之後，Data Guard會自動同步，不需要重建實體Standby，不過如果從另一個方向看，沒有啟動閃回，那就回不到READ WRITE前的狀态了）。

實體Standby特點如下：

（1）災難恢複及高可用性。實體Standby提供了一個健全、高效的災難恢複，以及高可用性的解決方案。更加易于管理switchover/failover角色轉換及在更短的計劃内或計劃外停機時間。

（2）資料保護。使用實體Standby資料庫，DG能夠確定即使面對無法預料的災害也能夠不丢失資料。前面也提到實體Standby是基于塊對塊的複制，是以與對象、語句無關，Primary資料庫上有什麼，實體Standby資料庫端也會有什麼。

（3）分擔Primary資料庫壓力。通過将一些備份任務、僅查詢的需求轉移到實體Standby資料庫，可以有效節省Primary資料庫的CPU及I/O資源。

（4）提升性能。實體Standby所使用的REDO應用技術使用最底層的恢複機制，這種機制能夠繞過SQL級代碼層，是以效率最高。

邏輯Standby

邏輯Standby也要通過Primary資料庫（或其備份，或其複制庫，如實體Standby）建立，是以在建立之初與實體Standby資料庫類似。不過由于邏輯Standby通過SQL應用的方式應用REDO資料，是以邏輯Standby的實體檔案結構，甚至資料的邏輯結構都可以與Primary不一緻。

與實體Standby不同，邏輯Standby正常情況下是以READ WRITE模式打開，使用者可以在任何時候通路邏輯Standby資料庫，就是說邏輯Standby是在OPEN狀态執行SQL應用。 注意：邏輯Standby雖然是以READ WRITE模式打開并應用REDO資料，不過被維護的對象預設處于隻讀狀态，無法在邏輯Standby端直接修改。對于邏輯standby 同樣有利也有弊，由于SQL應用自身特點，邏輯Standby對于某些資料類型及一些DDL/DML語句會有操作上的限制。可以在視圖DBA_LOGSTDBY_UNSUPPORTED 中檢視不支援的資料類型，如果使用了這種資料類型，則不能保證資料庫完全一緻。

邏輯Standby 的讀寫打開可以使它做報表系統，這樣減輕系統的壓力。

除了上述實體Standby中提到的類似災難恢複、高可用性及資料保護等特點之外，邏輯Standby還有下列一些特點：

（1）有效地利用備機的硬體資源。除災難恢複外，邏輯Standby資料庫還可用于其他業務需求。如通過在Standby資料庫建立額外的索引、物化視圖等提高查詢性能并滿足特定業務需要；又如建立新的SCHEMA（該SCHEMA在Primary資料庫端并不存在），然後在這些SCHEMA中執行那些不适于在Primary資料庫端執行的DDL或者DML操作等。

（2）分擔Primary資料庫壓力。邏輯Standby資料庫可以在保持與Primary同步時仍然置于打開狀态，這使得邏輯Standby資料庫能夠同時用于資料保護和報表操作，進而将主資料庫從報表和查詢任務中解脫出來，節約寶貴的CPU和I/O資源。

（3）平滑更新。可以通過邏輯Standby來實作如跨版本更新，為資料庫打更新檔等操作。應該說應用的空間很大，而帶來的風險卻很小（前提是如果你擁有足夠的技術實力。另外雖然實體Standby也能夠實作一些更新操作，但如果跨平台的話恐怕就力不從心了，是以此項沒有作為實體Standby的特點列出），我個人認為這是一種值得可行的線上的滾動的平滑的更新方式，如果你的應用支援建立邏輯Standby的話。

  資料保護模式

Data Guard 允許定義3鐘資料保護模式，分别是最大保護（Maximum Protection），最大可用（Maximum Availability）和 最大性能（Maximum Performance）

最大保護（Maximum Protection）

這種模式能夠確定絕無資料丢失。要實作這一步當然是有代價的，它要求所有的事務在送出前其REDO不僅被寫入到本地的Online Redologs，還要同時寫入到Standby資料庫的Standby Redologs，并确認REDO資料至少在一個Standby資料庫中可用（如果有多個的話）， 然後才會在Primary資料庫上送出事物 。如果出現了什麼故障導緻Standby資料庫不可用的話（比如網絡中斷），Primary資料庫會被Shutdown，以防止資料丢失。

使用這種方式要求Standby Database 必須配置Standby Redo Log，而Primary Database必須使用LGWR，SYNC，AFFIRM 方式歸檔到Standby Database.

這裡解釋下AFFIRM： AFFIRM僅當重做資料被寫入到備用重做日志後，目标才确認已收到，含有SYNC含義。NOAFFIRM當重做資料寫入到備用重做日志前目标就可以确認收到，含有ASYNC含義。

最高可用性（Maximum availability）

這種模式在不影響Primary資料庫可用前提下，提供最進階别的資料保護政策。其實作方式與最大保護模式類似，也是要求本地事務在送出前必須至少寫入一台Standby資料庫的Standby Redologs中，不過與最大保護模式不同的是，如果出現故障導緻Standby資料庫無法通路，Primary資料庫并不會被Shutdown，而是自動轉為最高性能模式，等Standby資料庫恢複正常之後，Primary資料庫又會自動轉換成最高可用性模式。

這種方式雖然會盡量避免資料丢失，但不能絕對保證資料完全一緻。這種方式要求Standby Database 必須配置Standby Redo Log，而Primary Database必須使用LGWR，SYNC，AFFIRM 方式歸檔到Standby Database.

最高性能（Maximum performance）

預設模式。 這種模式在不影響Primary資料庫性能前提下，提供最進階别的資料保護政策。事務可以随時送出，目前Primary資料庫的REDO資料至少需要寫入一個Standby資料庫，不過這種寫入可以是不同步的。如果網絡條件理想的話，這種模式能夠提供類似最高可用性的資料保護，而僅對Primary資料庫的性能有輕微影響。這也是建立Standby資料庫時，系統的預設保護模式。這種方式可以使用LGWR ASYNC 或者 ARCH 程序實作，Standby Database也不要求使用Standby Redo Log。

參考至：《大話Oracle RAC》 張曉明著

​​             http://www.5ienet.com/note/html/dg/dataguard-basic-what-is-dataguard.shtml​​

         ​​​         http://wenku.baidu.com/view/90a5f0270722192e4536f6b6.html​​​         

​​     http://wenku.baidu.com/view/8e797bebe009581b6bd9eb3a.html​​              http://oracle.chinaitlab.com/backup/784910.html