Oracle11g DataGuard 新特點小結

首先, 可以從活動主庫構建物理備庫是非常簡單. 此外, 將物理備庫轉換為邏輯資料庫也是輕而易舉. 而最大的優勢是, 現在, 可以高效地使用備庫通過某種方式來支援業務. Active DataGuard特性允許開啟備庫, 在進行查詢的同時應用歸檔的日誌. 快照備庫允許在其中執行生產資料庫負載, 然後閃回到起始點, 繼續正常的管理器恢復程式. 這兩個特性使使用者能夠利用備庫伺服器的處理功能, 極大地推動了到 11g 的升級.

1. 物理備庫新特點

1) 物理備庫可實時查詢

都知道11g以前的物理備庫, 可以是隻讀方式開啟資料庫, 但是這時Media Recovery(Redo Apply)過程就停止了, 如果備庫處於恢復的過程那麼資料庫就不能開啟, 11g解決了這個矛盾, 恢復的同時可以只讀開啟資料庫, 這有點類似邏輯備庫的功能. 這樣可以更大發揮物理備庫的作用(比如對於實時要求比較高的報表服務).

2) 加快備庫備份的速度

在Oracle10g引入了Block Tracking技術, 來監控那些資料庫是上次增量備份以來修改了的, 這樣可以加快增量備份的數度, 但是這個功能只能在主庫上有效, 在備庫是不支援這個功能的, Oracle11g解決了這個問題, 備庫的備份也支援Block Tracking, 這樣使用者可以在備庫上面快速執行備份, 減輕主庫負載.

3) 快照備庫

就是允許物理備庫以讀寫模式開啟, 但是同時沒有破壞它作為備庫的功能, 這個特性可以用來在物理備庫上面執行某些測試, 等測試完成, 把資料庫再置為物理備庫. 當然在備庫以讀寫方式開啟的時候它只能接收主庫傳過來的Redo, 但是不能應用這些Redo. 實際上因為就是在備庫上使用了Flashback技術來實現這個功能.

4) 提高Redo Apply的效能

Oracle11g可以利用並行技術來進行Redo Apply, 提高恢復的速度.

2. 邏輯備庫新特點

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-08 11.24.14.296807 PM ORA-16111: log mining and apply setting up

13-JAN-08 11.24.14.320487 PM Apply LWM 2677727, HWM 2677727, SCN 2677727

14-JAN-08 07.22.10.057673 PM APPLY_SET: APPLY_SERVERS changed to 2

14-JAN-08 07.22.11.034029 PM APPLY_SERVERS changed to 2

14-JAN-08 07.45.15.579761 PM APPLY_SET: EVENT_LOG_DEST changed to DEST_ALL

14-JAN-08 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

3. 其它改進

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'

--End--