Oracle 数据库11g版本dataguard创建的简单方法

Data Guard

了解 Active Data Guard 如何通过实时查询，同时应用归档的的日志、将物理备用数据库转换为快照备用数据库以及对基础架构的一系列改进措施，让您对备份环境的投资物有所值。

Oracle 数据库 11g 对 Data Guard 功能进行了多方面的增强，难以详尽说明。因此，在这里我将介绍一些我最感兴趣的功能增强。

备用数据库创建更加简单

首先，我们从创建物理备用数据库开始。在 Oracle 数据库 11g 中，物理备用数据库的创建已经变得极为简单，一条 RMAN 命令就可完成整个过程。以前您可能需要使用 Grid Control 向导界面在两台计算机之间完成 Data Guard 设置。在撰写本文时，Oracle 企业管理器网格控制 11g 还未推出，且 Database Control 没有 Data Guard 向导。但不管您是否使用过 SQL 命令，在 Oracle 数据库 11g 中设置 Data Guard 都是非常轻松的。过程如此简单，因此我将在此处介绍所有步骤。

假设您的主数据库名称为 prolin11，运行于 prolin1 服务器上。您想在 prolin2 服务器上设置一个备用数据库。备用数据库实例的名称应当为 pro11sb。以下为设置步骤：

在 prolin1 上，首先创建 spfile（如果您没有）。

SQL> create spfile from pfile;

这一步不是绝对必要的，但它可以简化这一过程。创建数据库后，重新启动 prolin11 数据库以使用 spfile。

尽管没有必要创建备用重做日志，这还是一个很好的做法。备用重做日志可使主数据库中发生的更改几乎实时地反应在备用数据库中，这一概念称为实时应用 (RTA)。因此，此处我们将在主数据库中创建一个备用重做日志（注意在主数据库中创建备用重做日志。RMAN 将在备用数据库中创建它们）：

SQL> alter database add standby redo logfile group 4 2> (‘+DG1/sby_redo01.rdo') size 50M; SQL> alter database add standby redo logfile group 5 2> (‘+DG1/sby_redo02.rdo') size 50M; SQL> alter database add standby redo logfile group 6 2> (‘+DG1/sby_redo03.rdo') size 50M; SQL> alter database add standby redo logfile group 7 2> (‘+DG1/sby_redo04.rdo') size 50M;

这将创建 4 个备用重做日志组。

在 prolin2 服务器上的 listener.ora 文件中创建一个 pro11sb 条目：

SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = pro11sb) (ORACLE_HOME = /opt/oracle/product/11g/db1) (SID_NAME = pro11sb) ) ) LISTENER = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = prolin2)(PORT = 1521)) )

重新载入监听器使之生效。

在 prolin1 上，在 $ORACLE_HOME/network/admin 下的 tnsnames.ora 文件中创建一个 pro11sb 数据库条目：

PRO11SB = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = prolin2)(PORT = 1521)) ) (CONNECT_DATA = (SID = pro11sb) ) )

在 prolin2 上的 Oracle Home/dbs 目录中，创建一个仅含一行的 initodba11sb.ora 文件：

db_name=prolin11

这将作为备用实例的初始化文件，使用稍后介绍的 RMAN 命令将自动填充其他参数。

在 prolin2 上，进入目录 $ORACLE_BASE/admin。在其中创建 pro11sb 目录，然后在 pro11sb 目录中创建 adump 目录，用于保存备用实例的审计文件。

在 prolin1 上，在 $ORACLE_HOME/dbs 目录下，您将找到实例的口令文件，通常命名为 orapworadba11。如果没有该文件（可能性很小），则创建一个。然后将文件复制到 prolin2 的 $ORACLE_HOME/dbs 下。将其复制到新文件 orapwodba11sb。这将确保主数据库的 sysdba 连接口令也可应用到备用数据库。

在 prolin2 上，以 NOMOUNT 状态启动实例 pro11sb。

$ sqlplus / as sysdba SQL> startup nomount

这将启动实例但不挂载任何东西。

完成开始的准备工作后，调用强大的 RMAN 脚本创建备用数据库。在 prolin1 上启动 RMAN 并运行以下脚本。您会发现将其保存到一个文件中，然后从 RMAN 提示符中运行这一脚本将更为简便。

connect target sys/oracle123@prolin11 connect auxiliary sys/oracle123@pro11sb run { allocate channel c1 type disk; allocate auxiliary channel s1 type disk; duplicate target database for standby from active database dorecover spfile parameter_value_convert 'prolin11','pro11sb' set db_unique_name='pro11sb' set db_file_name_convert='/prolin11/','/pro11sb/' set log_file_name_convert='/prolin11/','/pro11sb/' set control_files='/oradata/pro11sb/control01.ctl' set fal_client='pro11sb' set fal_server='prolin11' set standby_file_management='AUTO' set log_archive_config='dg_config=(prolin11,pro11sb)' set log_archive_dest_2='service=prolin11 LGWR ASYNC valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=pro11sb' set log_archive_dest_state_2='enable' set log_archive_format='pro11sb_%t_%s_%r.arc' ; sql channel c1 "alter system archive log current"; sq  channel s1 "alter database recover managed standby database using current logfile disconnect";
}

这一脚本将创建备用数据库，将相关的参数置于备用实例的 spfile 中，创建备用数据库的诊断目标，然后重新启动备用数据库。为助您了解这一操作的具体机理，您可以在此处查看 RMAN 命令的输出。

下面的两行连接到了主和备用实例。

connect target sys/oracle123@prolin11; connect auxiliary sys/oracle123@pro11sb;

因为您将口令文件复制到了备用数据库主机中，SYS 的口令保持不变，因此可成功连接到备用实例（无挂载的数据库）。下一步，执行以下代码：

duplicate target database for standby from active database spfile parameter_value_convert 'prolin11','pro11sb' set 'db_unique_name'='pro11sb' set 'db_file_name_convert'='/prolin11/','/pro11sb/' ... and so on ...

duplicate target database 命令首先通过远程服务器上的 SQL*Net 创建主数据库的镜像拷贝，而后基于主数据库创建备用数据库。完成拷贝后，它将在内部发出命令（switch clone datafile all;），这会将备用数据库作为克隆。脚本中的 set 命令将设置备用实例的 SPFILE 的参数，该数据库将作为备用数据库。再次查看 RMAN 的输出，了解幕后活动的所有信息。

构建物理数据库是如此的轻松，就如执行脚本一样简单！

Active Data Guard

许久以来，反对使用物理备用数据库构建 Data Guard 环境的传统因素之一是备用数据库的被动性。在 Oracle 数据库 10g 和以前的版本中，您可以打开物理备用数据库进行只读活动（卸去一些报告工作负载），但必须在停止恢复进程后。在这些版本中，如果 Data Guard 是您的 DR 解决方案的一部分，因为怕滞后，您不能承担长时暂停恢复进程的代价，所以物理备用数据库对于只读活动用处全无。

使用 Oracle 数据库 11g，情况将有所不同：您可以通过只读模式打开物理备用数据库，并重新启动恢复进程。这意味着您可以继续与主数据库保持同步，同时能使用备用数据库进行报告。（在以前的版本中，您也可从备用数据库中获取备份。）让我们看一下它的工作原理。

首选，取消管理备用数据库恢复：

SQL> alter database recover managed standby database cancel; Database altered.

然后以只读方式打开数据库：

SQL> alter database open read only; Database altered.

到这一步为止，过程与 11g 以前的版本相同。现在，11g 特性将显示其优势：以只读模式打开备用数据库时，您可以重新开始管理恢复进程。

SQL> alter database recover managed standby database disconnect; Database altered.

现在备用数据库处于管理恢复模式，在数据库打开时会应用日志文件。如何进行确认？很简单，查看主数据库的最大日志序列号并将其与备用数据库的相对比。在主数据库上，进行日志切换，然后检查最大的日志序列号：

SQL> alter system switch logfile; System altered. SQL> select max(Sequence#) from v$log; MAX(SEQUENCE#) -------------- 79

以只读模式打开备用数据库时进行了日志切换。检查备用数据库中的最大日志序列号：

SQL> select max(Sequence#) from v$log; MAX(SEQUENCE#) -------------- 79

也是 79，与主数据库中的值一样。这表示日志应用程序仍然在运行中。然而，您可能会问，这是表示应用了日志，可以看到在这一模式中主数据库中的更改吗？让我们来看看。在主数据库上，创建一个表：

SQL> create table test2 (col1 number); Table created.

然后进行几次日志切换，直至将那些日志应用至备用数据库。然后检查备用数据库：

SQL> desc test2 Name Null? Type ----------------------------------------- -------- --------------------------- COL1 NUMBER

立刻！表就出现在了备用数据库上，可供查询。

注意，在这一情况中我们可以使用“实时应用”，这样在网络可用时，对主数据库的更改可立即出现在备用数据库中。RTA 对 ADG 不是绝对必要的，但它可使 ADG 的帮助作用更大，因为您可以看到主数据库上最新的更改。

然而，具有安全意识的读者可能会有点担心。数据库处于只读模式中，所以不能向其中写入数据。如果主数据库的 audit_trail 参数设置为 DB（Oracle 数据库 11g 中的默认值），备用数据库中也相同，但因为是只读的，所以不能将审计跟踪写入数据库中。那这些审计跟踪到哪去了？

注意警报日志中显示的一行：

AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access

啊哈！审计跟踪并没有终止，在数据库打开时它们自动地转换为了 OS 文件。当您激活备用数据库时， audit_trail 将自动设置为 DB。

快照备用数据库

下面是一个典型场景：假设数据库上部署了一个新应用程序，您想知道它对数据库性能的影响。在 Oracle 数据库 11g 中，提供有一个绝佳的工具（数据库重放），它可以捕获 SQL 语句并将它们“回放”，但要注意：您必须运行它们以了解其影响。从测试系统捕获 SQL 语句而在生产系统上“回放”是不可行的。第一，没有部署；第二，即使部署了，您也不能承担让程序对其他表进行更改的后果。那么应怎么做来查看应用程序的影响呢？

Oracle 数据库 11g 给了您完美的答案，在 11g 中，您可以暂时将物理备用数据库转换为可更新的数据库，称为快照备用数据库 (Snapshot Standby Database)。在这一模式中，您可以运行您的应用程序（它可能会更改许多表），然后再分析其影响。评估影响后，您可以将数据库转换为备用数据库，然后进行常规恢复。您可以在数据库中创建一个恢复点来完成这一过程，使用 Flashback 数据库特性“闪回”至该点，恢复所有的更改。让我们看一下它的工作原理：

首先，在备用数据库上启动恢复进程（如尚未开始）：

SQL> alter database recover managed standby database disconnect; Database altered.

直到恢复进程得到一些日志文件。然后终止恢复。

SQL> alter database recover managed standby database cancel; Database altered.

在这一步，您可创建快照备用数据库。请谨记，它启用了闪回日志，因此，如果您没有配置闪回恢复区，将出现以下消息：

ORA-38784: Cannot create restore point 'SNAPSHOT_STANDBY_REQUIRED_01/12/2008 00:23:14'. ORA-38786: Flash recovery area is not enabled.

为了避免出现这种情况，您应先创建闪回恢复区。如果没有，不用担心，马上创建它：

SQL> alter system set db_recovery_file_dest_size = 2G; System altered. SQL> alter system set db_recovery_file_dest= '/db_recov'; System altered.

完成这些规定的步骤后，您可以使用以下简单的命令将这一备用数据库转换为快照备用数据库：

SQL> alter database convert to snapshot standby; Database altered.

现在重新利用数据库：

SQL> shutdown immediate ORA-01507: database not mounted ... ORACLE instance shut down. SQL> startup ORACLE instance started.

现在可以对数据库进行读写操作：

SQL> select open_mode, database_role 2 from v$database; OPEN_MODE DATABASE_ROLE ---------- ---------------- READ WRITE SNAPSHOT STANDBY

您可以在这一数据库中进行更改。这是使用数据库重放功能重放捕获负载的完美场所。然后，您可以在这一数据库中执行系统更改，并多次重放以分析更改的影响。因为这复制了生产数据库，所以“重放”真实地再现了工作负载。

完成测试后，您要将快照备用数据库恢复为普通的物理备用数据库。执行以下步骤：

SQL> connect / as sysdba Connected. SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount ORACLE instance started. ... Database mounted. SQL> alter database convert to physical standby; Database altered.

关机，挂载数据库，启动管理恢复。

SQL> shutdown ORA-01507: database not mounted ORACLE instance shut down. SQL> startup mount ORACLE instance started. ... Database mounted.

启动管理恢复进程：

SQL> alter database recover managed standby database disconnect;

现在备用数据库已恢复为管理恢复模式。当数据库处于快照备用模式时，主数据库的归档日志没有应用到其上，这自不必说。现在将应用它们，需要一些时间来进行弥补。

通过快照备用数据库，您可以使用备用数据库事先准确预计对生产数据库的更改。但这不是关键点，它还有另一个优势。请牢记，在这一情况中我们可以使用 RTA，这样在网络可用时，对主数据库的更改可立即出现在备用数据库中。但如果有人在主数据库上犯了一些错误，比如运行了大型的更新或更改了一些代码，那将如何呢？在以前的版本中，我们有意在备用数据库上采用延迟方法以阻止这些错误传送到备用数据库。但是有延迟也意味着不能正常激活备用数据库或作为生产数据库的活动副本。

现在不再需要这样了。因为您可以对备用数据库进行闪回操作，您不需要使用延迟了。如果有问题，您可以闪回到前一个状态。

物理到逻辑备用数据库的转换

您可以轻松地将物理备用数据库转换为逻辑备用数据库。步骤如下：

1. 备用数据库需要从某一位置获取数据字典信息。字典信息应当置于来自于主数据库中的重做流中。因此，在主数据库上，执行以下命令构建字典的 LogMiner 表： SQL> begin 2 dbms_logstdby.build; 3 end; 4 / PL/SQL procedure successfully completed.
2. 在备用数据库上，停止管理恢复进程： SQL> alter database recover managed standby database cancel; Database altered.
3. 现在，在备用数据库中执行以下命令以将它转换为逻辑数据库： SQL> alter database recover to logical standby pro11sb; Database altered.
4. 在主数据库上执行几个日志切换操作，确保创建归档日志并将它们发送至备用数据库： SQL> alter system switch logfile; System altered.
5. 在备用数据库侧，在一段时间后您可以看到更改数据库命令已经完成。现在备用数据库已经变成逻辑数据库。在警报日志中您可以看到以下内容： RFS[12]: Identified database type as 'logical standby'
6. 重新利用数据库： SQL> shutdown ORA-01507: database not mounted ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area 1071333376 bytes ... Database mounted. SQL> alter database open resetlogs; Database altered.
7. 现在这已经是一个逻辑备用数据库，您应当启用 SQL Apply 进程。 SQL> alter database start logical standby apply immediate;

逻辑数据库现在运行完全正常！将物理备用数据库转换为逻辑备用数据库后，若要将其转换回物理数据库，您需要使用一个特别子句 ("keep identity")，这稍后有述。

滚动升级

令 DBA 头痛的问题之一是确定合理关闭数据库一段时间以进行升级的必要性，这已经不是什么秘密。在 Oracle 数据库 11g 中， 如果您有备用数据库，通过滚动升级过程，这将变得极为简单：

1. 升级备用数据库。
2. 将应用程序转移至备用数据库。
3. 升级主数据库。
4. 将应用程序转移回原来的主数据库。

如果它是一个逻辑备用数据库，这一过程将非常简单，因为备用数据库只需应用从主数据库获得的 SQL。应用 SQL 后，就可在该数据库上轻松进行升级。您可以停止恢复，升级备用数据库、继续恢复以完成“弥补”，最后将备用数据库转换为主数据库。此后，您可以将原始的主数据库作为备用数据库，然后进行升级。最后，反转角色将原来的主数据库作为新的主数据库。

但是，许多备用数据库实际上是物理数据库，便于使用和管理。如果备用数据库是物理而非逻辑数据库，步骤也非常相似，仅有很小的差别：您需要暂时将备用数据库转换为逻辑临时数据库，然后再转换回物理备用数据库。关键点是临时，而非永久，因此您在执行转换命令时要使用“keep identity”，如下所示：

SQL> alter database recover to logical standby keep identity; Database altered.

该文件提供了更为详细的步骤指南。

其他改进

Data Guard 进程本身也有非常大的改进：

重做压缩

将归档日志从主数据库发送到备用数据库服务器，再将它们应用到数据库上，这一过程是 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> desc v$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 * from dba_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。下面是一个查询示例：

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

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 的升级。

返回到“Oracle 数据库 11g：面向 DBA 和开发人员的重要特性”主页

Arup Nanda 担任专职 Oracle DBA 已逾 12 年，他拥有 Oracle 数据库技术各个领域的经验，并在 2003 年荣获 Oracle 杂志授予的“年度 DBA”称号。Arup 经常在 Oracle 相关的活动中发表演讲并为 Oracle 相关刊物撰写文章，他还是一位 Oracle ACE 总监。他与其他人合作编写了四本书，其中包括《RMAN Recipes for Oracle Database 11g:A Problem Solution Approach》。