Oracle11g DataGuard新特性小结

首先, 可以从活动主库构建物理备库是非常简单。此外, 将物理备库转换为逻辑数据库也是轻而易举。而最大的优势是, 现在, 可以高效地使用备库通过某种方式来支持业务。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)  支持下面 O racle包和数据加密

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

其它改进

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 '

参考至:http://hi.baidu.com/edeed/blog/item/6410564e7d40d71ab3de0514.html

如有错误，欢迎指正

邮箱:[e-mail]