当然，在 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 操作没有影响闪回操作。该特性使闪回数据库非常强大和有用。 它的行为对闪回查询也适用。