高可用之3——DG基礎知識

整理自：http://blog.csdn.net/tianlesoftware/article/details/5514082

在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資料庫上執行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;

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

ARCH      CONNECTED             0          0 196

ARCH      CONNECTED             0          0 1944

ARCH      CONNECTED             0          0 3956

MRP0      WAIT_FOR_LOG          1      30843 N/A

RFS       RECEIVING             1      30838 2620

RFS       RECEIVING             1      30837 2612

RFS       RECEIVING             1      30833 2652

RFS       ATTACHED              1      30841 2628

RFS       ATTACHED              1      30835 2604

RFS       ATTACHED              1      30842 2608

已選擇11行。 

二． 資料保護模式

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

1. 最大保護（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.

2. 最高可用性（Maximum availability）

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

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

3. 最高性能（Maximum performance）

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

這種方式可以使用LGWR ASYNC 或者 ARCH 程序實作，Standby Database也不要求使用Standby Redo Log。

4. 修改資料保護模式步驟

1）關閉資料庫，重新開機到Mount 狀态，如果是RAC，需要關閉所有執行個體，然後隻啟動一個執行個體到mount狀态。

2）修改模式：

文法：ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE}; 

如：SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;

3) 打開資料庫： alter database open;

4) 确認修改資料保護模式：

SQL>select protection_mode,protection_level from v$database; 

三． 自動裂縫檢測和解決

      當Primary Database的某些日志沒有成功發送到Standby Database， 這時候發生了歸檔裂縫（Archive Gap）。

缺失的這些日志就是裂縫（Gap）。 Data Guard能夠自動檢測，解決歸檔裂縫，不需要DBA的介入。這需要配置FAL_CLIENT， FAL_SERVER 這兩個參數（FAL: Fetch Archive Log）。

從FAL 這個名字可以看出，這個過程是Standby Database主動發起的“取”日志的過程，Standby Database 就是FAL_CLIENT. 它是從FAL_SERVER中取這些Gap， 10g中，這個FAL_SERVER可以是Primary Database， 也可以是其他的Standby Database。

如：FAL_SERVER='PR1,ST1,ST2';

FAL_CLIENT和FAL_SERVER兩個參數都是Oracle Net Name。 FAL_CLIENT 通過網絡向FAL_SERVER發送請求，FAL_SERVER通過網絡向FAL_CLIENT發送缺失的日志。 但是這兩個連接配接不一定是一個連接配接。 是以FAL_CLIENT向FAL_SERVER發送請求時，會攜帶FAL_CLIENT參數值，用來告訴FAL_SERVER應該向哪裡發送缺少的日志。 這個參數值也是一個Oracle Net Name，這個Name是在FAL_SERVER上定義的，用來指向FAL_CLIENT.

當然，除了自動地日志缺失解決，DBA 也可以手工解決。 具體操作步驟如下：

1） 檢視是否有日志GAP： 

    SQL> SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG; 

　　SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; 

　  2） 如果有，則拷貝過來

3） 手工的注冊這些日志： 

SQL> ALTER DATABASE REGISTER LOGFILE '路徑'; 

四． 指定日志發送對象

1．VALID_FOR屬性指定傳輸及接收對象

LOG_ARCHIVE_DEST_n參數中的VALID_FOR屬性，用來指定傳輸的内容。從字面了解VALID_FOR就是基于那誰有效，該屬性有兩個參數值需要指定：REDO_LOG_TYPE和DATABASE_ROLE，我們基本上可以将其了解為：發送指定角色生成的指定類型的日志檔案，該參數的主要目的是為了確定，一旦發生角色切換操作後資料庫的正常運轉。

其中，REDO_LOG_TYPE和DATABASE_ROLE兩個參數可供選擇的參數值如下：

REDO_LOG_TYPE：可設定為ONLINE_LOGFILE、STANDBY_LOGFILE、ALL_LOGFILES。  

DATABASE_ROLE：可設定為PRIMARY_ROLE、STANDBY_ROLE、ALL_ROLES。 

注意：VALID_FOR參數預設值是：VALID_FOR=（ALL_LOGFILES,ALL_ROLES）。 

推薦手動設定該參數而不要使用預設值，在某些情況下預設的參數值不一定合适，如邏輯Standby在預設情況下就處于OPEN READ WRITE模式，不僅有REDO資料而且還包含多種日志檔案（Online Redologs、Archived Redologs及Standby Redologs）。

預設情況下，邏輯Standby資料庫生成的歸檔檔案和接收到的歸檔檔案在相同的路徑下，這既不便于管理，也極有可能帶來一些隐患。建議對每個LOG_ARCHIVE_DEST_n參數設定合适的VALID_FOR屬性。本地生成的歸檔檔案和接收到的歸檔檔案最好分别儲存于不同路徑下。

2．通過DB_UNIQUE_NAME屬性指定資料庫

DB_UNIQUE_NAME屬性是10g版本新增加的一個關鍵字，在之前版本并沒有這一說法。該屬性的作用是指定唯一的Oracle資料庫名稱，也正因有了DB_UNIQUE_NAME，REDO資料在傳輸過程中才能确認傳輸到DBA希望被傳輸到的資料庫上。

當然要確定REDO資料被傳輸到指定伺服器，除了在LOG_ARCHIVE_DEST_n參數中指定正确DB_UNIQUE_NAME屬性之外，還有一個初始化參數LOG_ARCHIVE_CONFIG也需要進行正确的配置。該參數除了指定Data Guard環境中的唯一資料庫名外，還包括幾個屬性，用來控制REDO資料的傳輸和接收：

SEND：允許資料庫發送資料到遠端。

RECEIVE：允許Standby接收來自其他資料庫的資料。

NOSEND,NORECEIVE：自然就是禁止喽。

例如，設定Primary資料庫不接收任何歸檔資料，可以做如下的設定：

LOG_ARCHIVE_CONFIG='NORECEIVE,DG_CONFIG= (PRI,ST) ' 

如果做了如上的設定，如果該伺服器發生了角色切換，那它也沒有接收REDO資料的能力。

五． Data Guard環境應配置的初始化參數

下列參數為Primary角色相關的初始化參數

DB_NAME

注意保持同一個Data Guard中所有資料庫DB_NAME相同

例如：DB_NAME=Dave

DB_UNIQUE_NAME

為每一個資料庫指定一個唯一的名稱，該參數一經指定不會再發生變化，除非DBA主動修改它

例如：DB_UNIQUE_NAME=DavePre

LOG_ARCHIVE_CONFIG

該參數用來控制從遠端資料庫接收或發送REDO資料，通過DG_CONFIG屬性羅列同一個Data Guard中所有DB_UNIQUE_NAME（含Primary資料庫和Standby資料庫），以逗号分隔，SEND/NOSEND屬性控制是否可以發送，RECEIVE/NORECEIVE屬性控制是否能夠接收

例如：LOG_ARCHIVE_CONFIG='DG_CONFIG=(DavePre,DaveDG)'

LOG_ARCHIVE_DEST_n

歸檔檔案的生成路徑。該參數非常重要，并且屬性和子參數也特别多(可以直接查詢Oracle官方文檔。Data Guard白皮書第14章專門介紹了該參數各屬性及子參數的功能和設定)。例如：

LOG_ARCHIVE_DEST_1='LOCATION=l:/oracle/oradata/Dave VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=DavePre'

LOG_ARCHIVE_DEST_STATE_n

是否允許REDO傳輸服務傳輸REDO資料到指定的路徑。該參數共擁有4個屬性值，功能各不相同。

REMOTE_LOGIN_PASSWORDFILE

推薦設定參數值為EXCLUSIVE或者SHARED，注意保證相同Data Guard配置中所有DB伺服器SYS密碼相同

以下參數為與Standby角色相關的參數（建議在Primary資料庫的初始化參數中也進行設定，這樣即使發生角色切換，新的Standby也能直接正常運作）

FAL_SERVER

指定一個Net服務名，該參數值對應的資料庫應為Primary角色。當本地資料庫為Standby角色時，如果發現存在歸檔中斷的情況，該參數用來指定擷取中斷的歸檔檔案的伺服器

例如：FAL_SERVER=DavePre

提示：FAL是Fetch Archived Log的縮寫

FAL_SERVER參數支援多個參數值的喲，互相間以逗号分隔

FAL_CLIENT

又指定一個Net服務名，該參數對應資料庫應為Standby角色。當本地資料庫以Primary角色運作時，向參數值中指定的站點發送中斷的歸檔檔案

例如：FAL_CLIENT=DaveDG

FAL_CLIENT參數也支援多個參數值，互相間以逗号分隔。

DB_FILE_NAME_CONVERT

Standby資料庫的資料檔案路徑與Primary資料庫資料檔案路徑不一緻時，可以通過設定DB_FILE_NAME_CONVERT參數的方式讓其自動轉換。該參數值應該成對出現，前面的值表示轉換前的形式，後面的值表示轉換後的形式

例如：DB_FILE_NAME_CONVERT='f:/oradata/DavePre','l:/oradata/DaveDG'

LOG_FILE_NAME_CONVERT

  使用方式與上相同，隻不過LOG_FILE_NAME_CONVERT專用來轉換日志檔案路徑

例如：

LOG_FILE_NAME_CONVERT='f:/oradata/DavePre','l:/oradata/DaveDG'

STANDBY_FILE_MANAGEMENT

如果Primary資料庫資料檔案發生修改（如建立、重命名等）則按照本參數的設定在Standby資料庫中作相應修改。設為AUTO表示自動管理。設為MANUAL表示需要手工管理

例如：STANDBY_FILE_MANAGEMENT=AUTO

對于歸檔失敗的處理，LOG_ARCHIVE_DEST_n參數有幾個屬性，可以用來控制歸檔過程中出現故障時應該采取的措施。

1．REOPEN 指定時間後再次嘗試歸檔

使用REOPEN=seconds（預設為300秒）屬性，在指定時間重複嘗試向歸檔目的地進行歸檔操作，如果該參數值設定為0，則一旦失敗就不會再嘗試重新連接配接并發送，直到下次REDO資料再被歸檔時會重新嘗試。

例如，設定REOPEN為100秒：

LOG_ARCHIVE_DEST_2='SERVICE=DavePrimary LGWR ASYNC REOPEN=100' 

2．ALTERNATE 指定替補的歸檔目的地

ALTERNATE屬性定義一個替補的歸檔目的地，所謂替補就是一旦主歸檔目的地因各種原因無法使用，則臨時向ALTERNATE屬性中指定的路徑寫。

LOG_ARCHIVE_DEST_1='LOCATION=/disk1 ALTERNATE=LOG_ARCHIVE_DEST_2' 

LOG_ARCHIVE_DEST_STATE_1=ENABLE  

LOG_ARCHIVE_DEST_2='LOCATION=/disk2' 

LOG_ARCHIVE_DEST_STATE_2=ALTERNATE 

上述參數設定歸檔路徑為/disk1，當/disk1路徑下無法成功歸檔時，自動嘗試向/disk2路徑下歸檔檔案。

從功能上來看，REOPEN與ALTERNATE是有一定重複的，不過需要注意一點，REOPEN屬性比ALTERNATE屬性的優先級要高，如果你指定REOPEN屬性的值>0，則LGWR（或ARCn）程序會首先嘗試向主歸檔目的地寫入，直到達到最大重試次數，如果仍然寫入失敗，才會向ALTERNATE屬性指定的路徑寫。

3．MAX_FAILURE 控制失敗嘗試次數

用REOPEN指定失敗後重新嘗試的時間周期，MAX_FAILURE則控制失敗嘗試的次數。

例如，設定LOG_ARCHIVE_DEST_1在本地歸檔檔案時，如果遇到錯誤，則每隔100秒嘗試一次，共嘗試不超過3次，設定如下：

LOG_ARCHIVE_DEST_1='LOCATION=E:/ora10g/oradata/jsspdg/ REOPEN=100 MAX_FAILURE=3'  

六． 實體Standby 和邏輯Standby 的差別

Standby資料庫類型分為兩類：實體Standby和邏輯Standby。

1．實體Standby

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

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

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級代碼層，是以效率最高。

2．邏輯Standby

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

與實體Standby不同，邏輯Standby正常情況下是以READ WRITE模式打開，使用者可以在任何時候通路邏輯Standby資料庫，就是說邏輯Standby是在OPEN狀态執行SQL應用。同樣有利也有弊，由于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的話。

七． Log應用服務（Log Apply Services）

Data Guard通過應用REDO維持Primary資料庫與各Standby資料庫之間的一緻性，在背景默默無聞地支撐着的就是傳說中的Log應用服務。Log應用服務又分以下兩種方式：

REDO應用：實體Standby資料庫專用，通過媒體恢複的方式保持與Primary資料庫的同步。

SQL應用：邏輯Standby資料庫專用，核心是通過LogMiner分析出SQL語句在Standby端執行。

是以實體Standby在應用REDO資料時必須是MOUNT狀态，而邏輯Standby則是以READ WRITE模式打開并應用REDO資料，不過被維護的對象預設處于隻讀狀态，無法在邏輯Standby端直接修改。

7.1  Log應用服務配置選項

預設情況下，Log應用服務會等待單個歸檔檔案全部接收之後再啟動應用，如果Standby資料庫配置了Standby Redologs，就可以打開實時應用（Real-Time Apply），這樣Data Guard就不需要再等待接收完歸檔檔案，隻要RFS程序将REDO資料寫入Standby Redologs，即可通過MRP/LSP實時寫向Standby資料庫。

7.1.1．REDO資料實時應用

啟動實時應用的優勢在于，REDO資料不需要等待歸檔完成，接收到即可被應用，這樣執行角色切換時，操作能夠執行得更快，因為日志是被即時應用的。

要啟動實時應用也簡單，前提是Standby資料庫端配置了Standby Redologs。

實體Standby要啟用實時應用，要在啟動REDO應用的語句後附加USING CURRENT LOGFIE子句，例如：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE ; 

邏輯Standby要啟用實時應用，隻需要在啟動REDO應用的語句後附加IMMEDIATE子句即可，例如：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 

7.1.2．REDO資料延遲應用

有實時就有延遲，某些情況下你可能不希望Standby資料庫與Primary太過同步，那就可以在Primary資料庫端發送REDO資料的相應LOG_ARCHIVE_DEST_n參數中指定DELAY屬性（機關為分鐘，如果指定了DELAY屬性，但沒有指定值，則預設是30分鐘）。

注意：該屬性并不是說延遲發送REDO資料到Standby，而是指明歸檔到Standby後，開始應用的時間。

例如：設定LOG_ARCHIVE_DEST_3的DELAY屬性為15分鐘：

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=DavePrimary ARCH VALID_ FOR=  

(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=Dave DELAY=15'; 

不過，如果DBA在啟動REDO應用時指定了實時應用，那麼即使在LOG_ ARCHIVE_DEST_n參數中指定了DELAY屬性，Standby資料庫也會忽略DELAY屬性。

另外，Standby端還可以在啟動REDO應用時，通過附加NODELAY子句的方式，取消延遲應用。

實體Standby可以通過下列語句取消延遲應用：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY; 

邏輯Standby可以通過下列語句取消延遲應用：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY; 

一般設定延遲應用的需求都是基于容錯方面的考慮，如Primary資料庫端由于誤操作，資料被意外修改或删除，隻要Standby資料庫尚未應用這些修改，你就可以快速從Standby資料庫中恢複這部分資料。不過自Oracle從9i版本開始提供FLASHBACK特性之後，對于誤操作使用FLASHBACK特性進行恢複，顯然更加友善快捷，是以DELAY方式延遲應用已經非常少見了。

7.2  應用REDO資料到Standby資料庫

7.2.1．實體Standby應用REDO資料

實體Standby啟動REDO應用，資料庫要處于MOUNT狀态或是OPEN READ ONLY狀态，啟動REDO應用的指令相信大家已經非常熟悉了。

前台應用：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE; 

語句執行完成後，不會将控制權傳回到指令行視窗，除非你手動中止應用。在這種情況下如果還需要對資料庫進行操作，隻能新開一個指令行連接配接，在Oracle 8i剛推出Standby特性時（那時不叫Data Guard），隻提供了這種方式。

背景應用：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; 

這是現在比較通用的方式，語句執行完後，控制權自動傳回到目前的指令行模式，REDO應用以背景程序運作。

啟動實時應用，附加USING CURRENT LOGFILE子句即可：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE; 

如果要停止REDO應用，執行下列語句即可：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 

7.2.2．邏輯Standby應用REDO資料

SQL應用的原理是将接收到的REDO資料轉換成SQL語句在邏輯Standby資料庫端執行，是以邏輯Standby需要啟動至OPEN狀态。

（1）啟動SQL應用。邏輯Standby資料庫啟動SQL應用沒有前、背景運作之說，語句執行完之後，控制權就會自動傳回目前指令行視窗。

要啟動SQL應用，直接執行下列語句即可：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY; 

如果要啟動實時應用，附加IMMEDIATE子句即可，例如：

（2）停止SQL應用，如：

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; 

由于是執行SQL語句的方式應用REDO資料，是以上述語句的執行需要等待目前執行的SQL觸發的事務結束，才能真正停止REDO應用的狀态。

如果不考慮事務執行情況，馬上停止REDO應用，可以通過下列的語句來完成：

SQL> ALTER DATABASE ABORT LOGICAL STANDBY APPLY;