增量合并
    假如你有以下的备份计划：星期天做level 0的完全备份，标识为level_0；星期一做level 1的增量备份，标识为level_1_mon；星期四做level 1的增量备份，标识为level_1_tue。如果数据库在星期六被损坏了，在10G之前你不得不恢复level_0然后再将所有6个增量备份实施上去，这样会消耗很长一段时间。这也是很多dba避免使用增量备份的原因之一。

Oracle 10g的RMAN从根本上改变了这种方式，现在的增量备份命令如以下这个样子：

RMAN> backup incremental level_1 for recover of copy with tag level_0 database; 

    这样RMAN再做增量备份level_1备份时会和标识为level_0的完全备份合并。经过这样的备份，level_0变成了那天的完全备份了。

    因此，在周四，标识为level_0的备份实际与level_1的增量备份合并，成了在周四做的完全备份。如果在周六数据库损坏了，你只需要将level_0的备份加上一些归档日志共同恢复就可以了。而不需要将增量备份也恢复。这种方式大大减少了恢复时间，使备份加速，并且避免了重新做一个增量备份。

压缩文件

    在基于磁盘备份的闪动恢复区域功能中，你还有一个很大的限制：磁盘容量。特别使当通过网络实现时——实际也经常是这么用的——强烈建议创建一个尽可能小的备份。在10G的RMAN中，你可以在备份命令中插入压缩文件的命令：

RMAN> backup as compressed backupset incremental level 1 database; 

    请注意这使用了COMPRESS子句。它压缩的备份文件有一个很重要的特点：当恢复时，RMAN可以无需解压文件直接读取它。为了确认是否压缩，可以在输出信息中检测是否有以下内容：

channel ORA_DISK_1: starting compressed incremental level 1 datafile backupset 

    你还可以通过在RMAN中list output确认备份是否被压缩：

RMAN> list output;
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ --------------- 

3 Incr 1 2M DISK 00:00:00 26-FEB-04
BP Key: 3 Status: AVAILABLE Compressed: YES Tag:
TAG20040226T100154
Piece Name:
/ora_flash_area/SMILEY10/backupset/2004_02_26/o1_mf_ncsn1_TAG20040226T100154_03w2m3lr_.bkp
Controlfile Included: Ckp SCN: 318556 Ckp time: 26-FEB-04
SPFILE Included: Modification time: 26-FEB-04 

    就如所有的压缩动作一样，这一方法会增大CPU的压力。但这也使你可以保留更多的备份在磁盘上以备恢复。另外，你还可以用RMAN来备份物理备份数据库以用于恢复主数据库。这一方法可以将备份资源从其他主机上卸载下来。

恢复预览

通过提供了能预览恢复操作功能，Oracle 10g变得很先进了：

RMAN> restore database preview;
… … 

你还可以预览特定的恢复操作，如：

RMAN>restore tablespace users preview;
… … 

预览功能使你能通过定期的检查来确认恢复时要做什么样的准备。

Resetlogs和恢复

    假如你丢失了当前的在线重做日志文件又不得不做一次不完全的数据库恢复。最大的问题时resetlogs。当不完全恢复后，你必须使用resetlogs子句来打开数据，它会设置日志线程的序列号为1，删除RMAN中早期的备份，使恢复操作更容易。在Oracle 9i和更低版本中，如果你需要将数据库从resetlogs中恢复到一个早期状态，你不得不把它恢复成一个不同的样子。在Oracle 10G中，你就不需要这样做了。由于控制文件增加了一些结构，RMAN可以在一次resetlogs操作之前或之后随时利用所有的备份来恢复数据库。做备份使没有必要关闭数据库了。这一新功能意味着在一次resetlogs操作以后数据库可以迅速的被用户打开。

来源：WWW.HelloDBA.COM