Oracle 11g DG概念與進程詳解____Oracle

RAC，Data Gurad，Stream 是Oracle 高可用性體系中的三種工具，每個工具即可以獨立應用，也可以相互配合。他們各自的側重點不同，適用情境也不同。

RAC它的強項在於解決單點故障和負載平衡，因此RAC方案常用於7*24的核心系統，但RAC方案中的資料只有一份，儘管可以通過RAID等機制可以避免儲存故障，但是資料本身是沒有冗餘的，容易形成單點故障。

Data Gurad通過冗餘資料來提供資料保護，Data Gurad 通過日誌同步機制保證冗餘資料和主要資料之前的同步，這種同步可以是即時，延時，同步，非同步多種形式。Data Gurad常用於異地容災和小企業的高可用性方案，雖然可以在Standby機器上執行唯讀查詢，從而分散Primary資料庫的效能壓力，但是Data Gurad決不是效能解決方案。

Stream是以oracle Advanced Queue為基礎實現的資料同步，提供了多種層級的靈活配置，並且Oracle提供了豐富的API等開發支援，Stream更適用在應用程式層面的資料共用。

 

一． 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資料庫上執行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進程（LGWR 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 RedoLog的歸檔，然後觸發Standby Database的MRP或者LSP進程恢複歸檔日誌。

 

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

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

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

 

  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 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;

 

 

SQL> set wrap off
SQL> select process,status,thread#,sequence#,client_pid from v$managed_standby;

PROCESS   STATUS          THREAD#  SEQUENCE#      CLIENT_PID
--------- ---------------------   ----------   -----------------------              ------------

ARCH      CONNECTED             0          0                                240