Oracle 10g R2新特性之备份和可用性特性(2)

当然，在 Oracle RAC 环境中，有多个数据库运行在多个主机上。 但在这样的环境中调用 RMAN 时，不得不只连接到一个实例（使用 TARGET=/）上，从而导致一个节点执行所有工作而其他节点却相对空闲。
　　在 Oracle 数据库 10g 第 2 版之前，让两个节点执行该工作的一个方法就是创建多个连接到多个实例的通道。 以下显示了一个相关 RMAN 命令的示例：

allocate channel = c1 type sbt_tape connect = 'rman/rmanpass@inst1';
allocate channel = c2 type sbt_tape connect = 'rman/rmanpass@inst2'; 

        该命令假设您有两个实例，即 inst1 和 inst2。 但该选项并不完全满足要求，这是因为它无法揭示某个节点出现了故障；当某个节点出现故障时，整个 RMAN 作业将发生故障。 此外，它并不创建真正的负载平衡配置。
　　在 Oracle 数据库 10g 第 2 版中，不必再为每个 RAC 节点显式分配一个通道来执行备份；您只需为操作定义并行度即可。 RMAN 自动创建多个并行流，并根据集群资源管理器连接到负载最小的实例。 除了负载平衡以外，它还提供了通道故障切换功能，以便将一个实例的连接故障切换到幸存节点。 此新特性增强了 RMAN 进程的强健度。

通过 RMAN 恢复临时文件
　　当您从 RMAN 备份恢复数据库时，所需执行的第一个操作就是重新创建临时表空间文件。 由于临时表空间不包含要恢复的永久对象，因此 RMAN 不备份它们 - 没有必要为非永久对象浪费备份资源。 但 Oracle 数据库需要临时表空间才能使许多操作高效运行。 因此，如果 RMAN 也备份它们岂不是很好？

　　在 Oracle 数据库 10g 第 2 版中，它做到了。 当您恢复数据库时，还将自动重新创建临时表空间文件。 以下是警报日志文件的片段：

ORA-01157: cannot identify/lock data file 201 - see DBWR trace file
ORA-01110: data file 201: '/u01/app/oracle/oradata/TEST/temp01.dbf'
ORA-27037: unable to obtain file status
Linux Error:2: No such file or directory
Additional information: 3
Sun Mar 27 20:29:00 2005
Errors in file /u01/app/oracle/admin/TEST/bdump/test_dbw0_15457.trc:
ORA-01186: file 201 failed verification tests
ORA-01157: cannot identify/lock data file 201 - see DBWR trace file
ORA-01110: data file 201: '/u01/app/oracle/oradata/TEST/temp01.dbf'
Sun Mar 27 20:29:00 2005
File 201 not verified due to error ORA-01157
Sun Mar 27 20:29:00 2005
Dictionary check complete
Sun Mar 27 20:29:00 2005
SMON: enabling tx recovery
Sun Mar 27 20:29:00 2005
Re-creating tempfile /u01/app/oracle/oradata/TEST/temp01.dbf

Oracle 数据库 10g 引入了闪回数据库，它通过撤消存储在闪回日志中的更改回滚整个数据库。 但请考虑以下情形：

1. 数据库活动正常。 记录已更新。
2. 数据库因重做日志文件中存在的物理损坏而崩溃。
3. 使用备份控制文件从备份恢复了数据库。
4. 使用 RESETLOGS 选项打开了数据库。
5. 数据库活动恢复。 以正常方式更新记录。 开发人员喊到“帮帮忙”！ 他更新了错误的记录集。 他请求闪回该数据库。

　　当使用 RESETLOGS 选项打开数据库时，该数据库从编号为 1 的 SCN 开始。因此，新配置文件不知道过去更新的 SCN 编号。 由于闪回数据库依赖 SCN 编号，因此该特性能否在该情形下起作用？
　　在 Oracle 数据库 10g 第 2 版中，它将起作用，这是因为该数据库将它的前一个副本存储在控制文件中，并对频繁地使用它。 这种情况下将查询前一个副本，并使用它将数据库闪回到不同的时间，即使在同时重置了 SCN 编号的情况下也是如此。
　　我们来看一个示例： 首先，检查帐号 3 的帐户持有者。

SQL> select first_name, last_name
2  from accounts
3  where acc_no = 3;
FIRST_NAME                     LAST_NAME
------------------------------ ----------- 
Alan                           Smith

现在更新名称：

SQL> update accounts
2  set first_name = 'John'
3  where acc_no = 3;

现在，毁坏数据库，从备份恢复，然后在 RESETLOGS 选项中打开已恢复的数据库。

　　假设一段时间过后，大厅角落里传来了一个气急败坏的声音“靠”，然后就有人请您将数据库闪回到先前的某个时间点，而这个时间点恰好位于 RESETLOGS 操作之前。

　　这时只需发出以下命令即可。

SQL> Flashback database to before resetlogs;

该命令恰好把数据库闪回到 RESETLOGS 之前的 SCN。 执行该命令后，再次检查该表。

SQL> select first_name, last_name
2  from accounts
3  where acc_no = 3;
FIRST_NAME                     LAST_NAME
------------------------------ -----------
Alan                           Smith

您可以看到，RESETLOGS 操作没有影响闪回操作。该特性使闪回数据库非常强大和有用。 它的行为对闪回查询也适用。

还记得 SQL 中保存点的概念吗？ 在一个事务中，您可以创建保存点，进行某些修改，创建另一个保存点，等等。 如果这些更改不是您想要的，则您所要做的就是将它们回滚到某个具体的保存点。
　　现在，我们将介绍 Oracle 数据库 10g 中引入的一个新功能 — 闪回数据库。通过它您可以将数据库倒回到前一个时间点。 在这种情况下拥有一个与保存点类似的功能（即能够倒回到一个有名称的点，而不仅仅是一个时间点）岂不是很好？
　　在 Oracle 数据库 10g 第 2 版中，您可以使用一个名为恢复点的新功能来实现该操作。以下是它的工作方式。 假设有一个长期运行的处理（涉及多个必须按顺序运行的批处理程序）。以下是事件序列：
        1、创建恢复点 rp1
        2、运行批处理作业 1
        3、创建恢复点 rp2
        4、运行批处理作业 2
等等。 批处理作业 2 在执行过程中失败，您需要将数据库恢复到一致的状态。 您不必将它一直恢复到运行的开始阶段。 由于恢复点 rp2 是在批处理作业执行之前创建的，因此只需将数据库闪回到该恢复点。
　　使用以下代码创建一个恢复点
        create restore point before_monthend_200503;

　　现在根据当前的数据库时间和 SCN 创建了恢复点 BEFORE_MONTHEND_200503。 如果要确保可以将数据库闪回到某个特定恢复点，可以通过按如下所示创建有保证的恢复点来指定 guarantee：
        create restore point before_monthend_200503
        guarantee Flashback database;
　　可以通过从动态性能视图 V$RESTORE_POINT 中执行 SELECT 来确认该恢复点是否存在：

SQL> select * from v$restore_point;
SCN DATABASE_INCARNATION# GUA STORAGE_SIZE
---------- --------------------- --- ------------
TIME
---------------------------------------------------
NAME
---------------------------------------------------
1429811                     1 YES      8192000
27-MAR-05 05.18.39.000000000 PM
BEFORE_MONTHEND_200503

稍后当您要将数据库闪回到该恢复点时，您只需发出： 
         flashback database to restore point before_monthend_200503;
如果检查警报日志，它将显示一个类似如下的行：

SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;
FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------ ------------------------- ---------------
CONTROLFILE                   0                         0               0
ONLINELOG                     0                         0               0
ARCHIVELOG                  .02                       .02               1
BACKUPPIECE               68.98                      1.02              10
IMAGECOPY                     0                         0               0
FLASHBACKLOG                .95                         0               3

使用该视图，您可以立即看到快速恢复区中的可用文件类型。 但它只显示百分比，因此您如何确定实际值？ 只需查询视图 $RECOVERY_FILE_DEST 即可。

SQL> select * from V$RECOVERY_FILE_DEST;
NAME
----------------------------------------------------------
SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
----------- ---------- ----------------- ---------------
/home/oracle
2147483648 1502122496          22201856              14

        该查询显示恢复区的总大小为 16384000。闪回日志占用 SPACE_LIMIT 列的 0.95%（上一个查询中所示），因此您可
以计算所占用空间的实际大小。 它还显示了从快速恢复区中不同类型的备份中可以回收的空间大小。 例如，您可以因为备份可能已过期而回收 1.02% 的已占用空间。 使用该视图，您可以针对快速恢复区使用率和大小进行智能化的预测。

　　Oracle EntERPrise Manager 通过向 Recovery Settings 页（显示快速恢复区域中的文件细分）中添加一个饼图来利用新的 V$RECOVERY_FILE_DEST 视图：

　　DBA 工作（尤其是生产支持 DBA 的工作）的独特方面之一就是成功、可靠以及高效地进行备份和恢复的能力。 在 Oracle 数据库 10g 第 2 版中，该领域中的增强使 DBA 的工作变得更加容易和可靠。