轉載標註：
原文地址：http://blog.csdn.net/tianlesoftware/article/details/5514082
五．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;