23_11g新特性_Data Guard(3)

重做压缩

将归档日志从主数据库发送到备用数据库服务器，再将它们应用到数据库上，这一过程是 Data Guard 的前提。主、备用数据库间时间差的一个重要部分是传输归档日志的时间。如果对重做流进行压缩，可以将这一过程加快一些。

在 Oracle 数据库 11g 中，您可使用 SQL*Net 并将压缩参数设为真，从而压缩传输至备用服务器的重做流。这一过程只适用于在 Gap Resolution 间传输的日志。以下命令可用于在本文开始时提供的示例中启用压缩。

alter system set log_archive_dest_2 = 'service=pro11sb LGWR ASYNC valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=pro11sb compression=enable'

网络超时

Data Guard 环境的工具原理是：连接备用服务器端的数据库实例，向备用服务器发送重做数据。如果实例没有及时响应，日志传输服务将等待指定的超时值，然后放弃。可以在 Oracle 数据库中使用 net_timeout 参数设置超时值。在最大限度的保护模式下，日志传输服务将尝试 20 次后放弃。

但首选您要知道日志传输中当前的延迟。新视图 v$redo_dest_resp_histogram 以直方图形式表示了该时间值：

SQL>descv$redo_dest_resp_histogram

Name Null? Type

---------------------- ------- --------------

DEST_ID NUMBER

TIME VARCHAR2(20)

DURATION NUMBER

FREQUENCY NUMBER

该视图在给定圆柱中向您显示了传输花费时间中的次数。如果运行几天后再查看此视图，您可以清楚要设置的超时时间。然后可使用以下命令设置超时时间： alter system set log_archive_dest_2 = 'service=pro11sb LGWR ASYNC valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=pro11sb compression=enable net_timeout=20'

这还是来自于上面的示例。注意参数值中的子句“net_timeout=20”。 可动态修改的参数

在运行逻辑备用数据库环境的过程中，您需要调整该过程并修改一些参数值。在 Oracle 数据库 11g 中，这些参数中的大部分可以在线更新。您可以通过查询视图 dba_logstdby_parameters 来查看这些参数。

col name format a30

col value format a10

col unit format a10

col setting a6

col setting format a6

col dynamic format a7

select *

fromdba_logstdby_parameters

order by name

/

NAME VALUE UNIT SETTIN DYNAMIC ------------------------------ ---------- ---------- ------ ------- APPLY_SERVERS 5 SYSTEM YES EVENT_LOG_DEST DEST_EVENT SYSTEM YES S_TABLE

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 YES

注意列 DYNAMIC，其中显示了值是否可动态修改。几乎所有的参数都是动态的。例如，要更改参数 APPLY_SERVERS 同时不停止备用数据库，您可以使用： SQL> begin

2 dbms_logstdby.apply_set('APPLY_SERVERS',2);

3 end;

4 /

这会将 apply_servers 设置为 2，从而无需关闭备用数据库即可完成这一任务。 SQL 应用事件表

在 Oracle 数据库 10g 中，与 SQL Apply 相关的事件将写入到警报日志中，这没有很大的用处，因为您可能想编写脚本检查它们，用于警报或报告。在 Oracle 数据库 11g 中，默认将事件写入 SYSTEM 模式下的新表 LOGSTDBY$EVENTS。下面是一个查询示例：

selectevent_time, error

fromsystem.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”来达到这一目的：

begin

dbms_logstdby.apply_set('EVENT_LOG_DEST','DEST_ALL');

end;

该任务可以动态完成，现在事件将同时传输到表和警报日志中。执行这一命令后，您可以检查警报日志，除可能的大量的 SQL Apply 事件外，它至少还更改了这两行：

LOGSTDBY: APPLY_SET: EVENT_LOG_DEST changed to DEST_ALL

LOGSTDBY status: EVENT_LOG_DEST changed to DEST_ALL

结论

首先，您了解了从活动主数据库构建物理备用数据库是如此的简单。此外，您还知晓了将物理备用数据库转换为逻辑数据库是如此 的轻而易举。而最大的优势是，现在，您可以高效地使用备用数据库通过某种方式来支持业务。Active Data Guard 特性允许您打开备用数据，在进行查询的同时应用归档的日志。快照备用数据库允许您在其中运行生产数据库负载，然后闪回到起始点，继续正常的管理器恢复进 程。这两个特性使用户能够利用备用服务器的处理功能，极大地推动了到 11g 的升级。