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 '