Oracle Data Guard 理論知識
前言
Data Gurad 通過冗餘資料來提供資料保護，Data Gurad 通過日誌同步機制保證冗餘資料和主資料之前的同步，這種同步可以是實時，延時，同步，非同步多種形式。Data Gurad 常用於異地容災和小企業的高可用性方案，雖然可以在Standby 機器上執行只讀查詢，從而分散Primary 蘇菊哭的效能壓力，但是Data Gurad 決不是效能解決方案。
在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;