需要了解的Data Guard理論知識（一）

在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 只是一個角色概念，並不固定在某個資料庫中。

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資料庫上執行SQL語句實現同步，這種方式叫SQL Apply。

物理Standby接收完Primary資料庫生成的REDO資料後，以介質恢復的方式實現同步，這種方式也叫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;

注： 上述內容整理自 張曉明《大話 Oracle RAC 》和  李丙洋 《塗抹 Oracle 》