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 更適用在應用層面的數據共享。
參考：------------- https://www.cnblogs.com/jimeper/archive/2013/04/11/3014078.html
增量服務從源數據庫獲取增量數據存儲到消息服務中間件中，分發服務訂閱消息中間件的增量數據並寫入到目標數據庫。目前實現mssql、mysql、oracle等關系型數據庫之間的數據同步。
在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子句即可，例如：
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;