23_11g新特性_Data Guard(2)

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 fromv$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 表：

2. SQL> begin

3. 2 dbms_logstdby.build;

4. 3 end;

5. 4 /

6.

7. PL/SQL procedure successfully completed.

8. 在备用数据库上，停止管理恢复进程：

9. SQL> alter database recover managed standby database cancel; 10.

11.Database altered.

12.现在，在备用数据库中执行以下命令以将它转换为逻辑数据库：

13.SQL> alter database recover to logical standby pro11sb; 14.

15.Database altered.

如果您没有执行步骤 1，以上命令将处于等待状态，因为没有发现字典信息。不要担心，只需执行步骤 1 即可。如果启用了 RTA， …… 此处隐藏：3329字，全部文档内容请下载后查看。喜欢就下载吧 ……