Oracle Data Guard 理論知識

        RAC， Data Gurad， Stream

是Oracle 高可用性體系中的三種工具，每個工具即可以獨立應用，也可以互相配合。 他們各自的側重點不同，适用場景也不同。

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

        Data Gurad 通過備援資料來提供資料保護，Data Gurad 通過日志同步機制保證備援資料和主資料之前的同步，這種同步可以是實時，延時，同步，異步多種形式。DataGurad常用于異地容災和小企業的高可用性方案，雖然可以在Standby機器上執行隻讀查詢，進而分散Primary 資料庫的性能壓力，但是DataGurad決不是性能解決方案。

        Stream 是以Oracle Advanced Queue為基礎實作的資料同步，提供了多種級别的靈活配置，并且Oracle提供了豐富的API等開發支援，Stream更适用在應用層面的資料共享。

      在Data Gurad 環境中，至少有兩個資料庫，一個處于Open 狀态對外提供服務，這個資料庫叫作PrimaryDatabase。第二個處于恢複狀态，叫作StandbyDatabase。

運作時primary Database對外提供服務，使用者在PrimaryDatabase 上進行操作，操作被記錄在聯機日志和歸檔日志中，這些日志通過網絡傳遞給StandbyDatabase。

這個日志會在StandbyDatabase上重演，進而實作Primary Database和Standby

Database 的資料同步。

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

       如果是可預見因素需要關閉Primary Database，比如軟硬體更新，可以把Standby Database

切換為Primary Database 繼續對外服務，這樣即減少了服務停止時間，并且資料不會丢失。如果異常原因導緻Primary Database不可用，也可以把StandbyDatabase強制切換為Primary

Database繼續對外服務，這時資料損失程度和配置的資料保護級别有關系。是以Primary和Standby隻是一個角色概念，并不固定在某個資料庫中。

 一． Data Guard 架構

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

            1） 日志發送（Redo Send）

            2） 日志接收（Redo Receive）

            3） 日志應用（Redo Apply）

       1. 日志發送（Redo Send）

       Primary Database 運作過程中，會源源不斷地産生Redo 日志，這些日志需要發送到StandyDatabase。這個發送動作可以由PrimaryDatabase

的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（RemoteFileServer）程序。

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

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

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

 說明：

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

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

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

        使用ARCH程序傳遞最大問題在于：

Primary Database隻有在發生歸檔時才會發送日志到StandbyDatabase。 如果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程序（NetworkServerProcess），再由LNSn（LGWRNetworkServerprocess）程序把日志通過網絡發送給遠端的目的地，每個遠端目的地對應一個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把日志寫入StandbyRedoLog就會立即進行恢複；

           歸檔恢複： 在完成對Standby Redo

Log 歸檔才觸發恢複。

           Primary Database預設使用ARCH程序，如果使用LGWR程序必須明确指定。使用LGWRSYNC方式時，可以同時使用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程序就會報錯。也就是說PrimaryDatabase的LGWR程序依賴于網絡狀況，有時這種要求可能過于苛刻，這時就可以使用LGWRASYNC方式。

它的工作機制如下：

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

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

3） Primary Database的Online Redo Log 寫滿後發生Log Switch，觸發歸檔操作，也觸發StandbyDatabase對StandbyDatabase對StandbyRedo

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（RemoteFileServer）程序接收到日志後，就把日志寫到StandbyRedoLog或者ArchivedLog檔案中，具體寫入哪個檔案，取決于Primary

的日志傳送方式和Standby database的位置。如果寫到StandbyRedoLog檔案中，則當Primary

Database發生日志切換時，也會觸發StandbyDatabase上的StandbyRedoLog 的日志切換，并把這個Standby

Redo Log歸檔。 如果是寫到ArchivedLog，那麼這個動作本省也可以看作是個歸檔操作。

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

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（PhysicalStandby）和邏輯Standby（Logical

Standby）。

      Physical Standby 使用的是MediaRecovery技術，在資料塊級别進行恢複，這種方式沒有資料類型的限制，可以保證兩個資料庫完全一緻。Physical

Standby資料庫隻能在Mount狀态下進行恢複，也可以是打開，但隻能已隻讀方式打開，并且打開時不能執行恢複操作。

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

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

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

        一種是實時應用（Real-Time Apply）， 這種方式必須StandbyRedoLog，每當日志被寫入StandbyRedo

Log時，就會觸發恢複，使用這種方式的好處在與可以減少資料庫切換（Switchover或者Failover）的時間，因為切換時間主要用在剩餘日志的恢複上。

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

       如果是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 00 240

ARCH CONNECTED 00 196

ARCH CONNECTED 00 1944

ARCH CONNECTED 00 3956

MRP0 WAIT_FOR_LOG 130843 N/A

RFS RECEIVING 130838 2620

RFS RECEIVING 130837 2612

RFS RECEIVING 130833 2652

RFS ATTACHED 130841 2628

RFS ATTACHED 130835 2604

RFS ATTACHED