首先, 可以從活動主庫構建物理備庫是非常簡單. 此外, 將物理備庫轉換爲邏輯數據庫也是輕而易舉. 而最大的優勢是, 現在, 可以高效地使用備庫通過某種方式來支持業務. Active DataGuard特性允許打開備庫, 在進行查詢的同時應用歸檔的日誌.
快照備庫允許在其中運行生產數據庫負載, 然後閃回到起始點, 繼續正常的管理器恢復進程. 這兩個特性使用戶能夠利用備庫服務器的處理功能, 極大地推動了到 11g 的升級.
- 物理備庫新特點
（1）物理備庫可實時查詢
都知道11g以前的物理備庫, 可以是隻讀方式打開數據庫, 但是這時Media Recovery(Redo Apply)過程就停止了, 如果備庫處於恢復的過程那麼數據庫就不能打開, 11g解決了這個矛盾, 恢復的同時可以只讀打開數據庫, 這有點類似邏輯備庫的功能. 這樣可以更大發揮物理備庫的作用(比如對於實時要求比較高的報表服務).
（2）加快備庫備份的速度
在Oracle10g引入了Block Tracking技術, 來監控那些數據庫是上次增量備份以來修改了的, 這樣可以加快增量備份的數度, 但是這個功能只能在主庫上有效, 在備庫是不支持這個功能的, Oracle11g解決了這個問題, 備庫的備份也支持Block Tracking, 這樣用戶可以在備庫上面快速執行備份, 減輕主庫負載.
（3）快照備庫
就是允許物理備庫以讀寫模式打開, 但是同時沒有破壞它作爲備庫的功能, 這個特性可以用來在物理備庫上面執行某些測試, 等測試完成, 把數據庫再置爲物理備庫. 當然在備庫以讀寫方式打開的時候它只能接收主庫傳過來的Redo, 但是不能應用這些Redo. 實際上因爲就是在備庫上使用了Flashback技術來實現這個功能.
（4）提高Redo Apply的性能
Oracle11g可以利用並行技術來進行Redo Apply, 提高恢復的速度. - 邏輯備庫新特點
（1）支持的數據類型更多了
XMLType data type(CLOB存儲)
（2）支持下面Oracle包和數據加密
DBMS_FGA(Fine Grained Auditing)
DBMS_RLS(Virtual Private Database)
實際上就是支持在邏輯備庫上面支持精細的審計功能和虛擬數據庫功能
Transparent Data Encryption(TDE)的支持
備庫上面支持並行DDL
（3） Fast-Start Failover
更快速執行失敗切換, 更精細控制觸發Failover的事件, 比如可以根據某個ORA的錯誤號來發出切換.
（4）可動態修改的參數
在運行邏輯備庫環境的過程中, 需要調整該過程並修改一些參數值. 在Oracle11g中, 這些參數中的大部分可以在線更新. 可以通過查詢視圖dba_logstdby_parameters來查看這些參數.
SQL> col name format a30
col value format a20
col unit format a10
col setting format a7
col dynamic format a7
SQL> select * from dba_logstdby_parameters order by name;
NAME VALUE UNIT SETTING DYNAMIC
----------- ----------------- ---------- ------- -------
ALLOW_TRANSFORMATION FALSE SYSTEM NO
APPLY_SERVERS 5 SYSTEM YES
EVENT_LOG_DEST DEST_EVENTS_TABLE SYSTEM YES
LOG_AUTO_DELETE TRUE SYSTEM YES
LOG_AUTO_DEL_RETENTION_TARGET 1440 MINUTE SYSTEM YES
MAX_EVENTS_RECORDED 10000 SYSTEM YES
MAX_SERVERS 9 SYSTEM YES
MAX_SGA 30 MEGABYTE SYSTEM YES
PREPARE_SERVERS 1 SYSTEM YES
PRESERVE_COMMIT_ORDER TRUE SYSTEM NO
RECORD_APPLIED_DDL FALSE SYSTEM YES
RECORD_SKIP_DDL TRUE SYSTEM YES
RECORD_SKIP_ERRORS TRUE SYSTEM YES
RECORD_UNSUPPORTED_OPERATIONS FALSE SYSTEM NO
注意列DYNAMIC, 其中顯示了值是否可動態修改. 幾乎所有的參數都是動態的. 例如, 要更改參數APPLY_SERVERS同時不停止備庫, 可以使用:
SQL> exec dbms_logstdby.apply_set('APPLY_SERVERS',2);
這會將apply_servers設置爲2, 從而無需關閉備庫即可完成這一任務.
（5）SQL 應用事件表
在Oracle10g中, 與SQL Apply相關的事件將寫入到警報日誌中, 這沒有很大的用處, 因爲可能想編寫腳本檢查它們, 用於警報或報告. 在Oracle11g中, 默認將事件寫入SYSTEM模式下的新表LOGSTDBY$EVENTS. 下面是一個查詢示例:
SQL> select event_time, error from system.logstdby$events order by 1;
EVENT_TIME ERROR
----------------------------- -------------------------------------------------
13-JAN-19 11.24.14.296807 PM ORA-16111: log mining and apply setting up
13-JAN-19 11.24.14.320487 PM Apply LWM 2677727, HWM 2677727, SCN 2677727
14-JAN-19 07.22.10.057673 PM APPLY_SET: APPLY_SERVERS changed to 2
14-JAN-19 07.22.11.034029 PM APPLY_SERVERS changed to 2
14-JAN-19 07.45.15.579761 PM APPLY_SET: EVENT_LOG_DEST changed to DEST_ALL
14-JAN-19 07.45.16.430027 PM EVENT_LOG_DEST changed to DEST_ALL
將事件保存在表中非常有用, 原因衆多, 其中之一就是操作和報告更加方便. 但有時將它們保存在警報日誌中也很有用, 特別是當使用一些監視工具來掃描警報日誌以獲取錯誤和消息時. 可以將邏輯備庫應用參數"event_log_dest"設置爲"DEST_ALL"來達到這一目的:
SQL> exec dbms_logstdby.apply_set('EVENT_LOG_DEST','DEST_ALL');
該任務可以動態完成, 現在事件將同時傳輸到表和警報日誌中. 執行這一命令後, 可以檢查警報日誌, 除可能的大量的SQL Apply事件外, 它至少還更改了這兩行:
LOGSTDBY: APPLY_SET: EVENT_LOG_DEST changed to DEST_ALL
LOGSTDBY status: EVENT_LOG_DEST changed to DEST_ALL
- 其它改進
（1）重做壓縮
將歸檔日誌從主庫發送到備庫服務器, 再將它們應用到數據庫上, 這一過程是DataGuard的前提. 主備庫間時間差的一個重要部分是傳輸歸檔日誌的時間. 如果對重做流進行壓縮, 可以將這一過程加快一些. 在Oracle11g中, 可使用SQL*Net並將壓縮參數設爲真, 從而壓縮傳輸至備庫服務器的重做流. 這一過程只適用於在Gap Resolution間傳輸的日誌. 以下命令可用於啓用壓縮.
SQL> alter system set log_archive_dest_2 = 'service=DG_ORCLSTD LGWR ASYNC valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=ORCLSTD compression=enable'
（2）網絡超時
DataGuard環境的工具原理是: 連接備庫服務器端的數據庫實例, 向備庫服務器發送重做數據. 如果實例沒有及時響應, 日誌傳輸服務將等待指定的超時值, 然後放棄. 可以在Oracle數據庫中使用net_timeout參數設置超時值. 在最大限度的保護模式下, 日誌傳輸服務將嘗試20次後放棄.
但首選要知道日誌傳輸中當前的延遲. 新視圖v$redo_dest_resp_histogram以直方圖形式表示了該時間值. 該視圖在給定圓柱中向顯示了傳輸花費時間中的次數. 如果運行幾天後再查看此視圖, 可以清楚要設置的超時時間. 然後可使用以下命令設置超時時間:
SQL> alter system set log_archive_dest_2 = 'service=DG_ORCLSTD LGWR ASYNC valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=ORCLSTD compression=enable net_timeout=20'
