3。4提升恢复的性能 恢复的性能也非常重要，因为备份的目的就是为了恢复，备份的策略也是要能满企业恢复时限要求的备份策略。影响恢复性能的因素总结起来大体有如下几方面：
3.4.1 数据库的性能
同备份一样，RMAN的恢复一样需要良好的数据库性能，主要有以下几方面：
I/O：Recovery是一个读和写都密集型的操作，它需要读出归档日志的内容，把数据文件相关的blocks读到Cache，也要把Recover完的脏块回写到
硬盘，因此数据库要有良的IO均衡和良好的IO性能。
DBWR的性能：Recovery过程中的脏块回写到数据文件的工作是由DBWR进程来完成的，因此DBWR的性能也会对Recovery的性能产生影响。DBWR的瓶颈可以通过v$session_wait视图的”free buffer waits”表现出来，如果在各上时点总有一些这样的等待说明DBWR的写速度存在着瓶颈。提高DBWR写速度的方法有○1启用异步IO,○2多加一个DBWR进程。
CPU的性能：每一个需要recover的数据块在重做日志应用其上前首先要被读入Buffer cache中，因此这便有一个栓(Latch)获取的过程，包括cache buffers chains和cache buffers lru chain两种栓，获取栓对数据块修改的过程都需要CPU资源，因此在Recovery过程中要确保有充足的CPU带宽，特别是在做并行Recovery的时候。
3.4.2 恢复要需用到的归档日志、增量备份的量
当基础级别的备份被RMAN Restore后，RMAN会继续找是否有增量的备份，如果找到那么Restore增量备份，最后Restore归档日志，并以归档日志完成Recovery。理论及实测都表明，增量备份会加快数据恢复的速度，用到的归档量越多恢复的时间会越加长，这与备份策略的设计有关。
在Oracle9i及之前的版本因没有数据文件变化块记录的机制，因而虽然增量备份减少了输出的数据量，但其还是要读所有的数据文件中的所有的块，会对正常的应用系统的性能产生一些影响，所以在实际过程中，使用Oracle9I及之前的版本的企业一般都不会增量备份，而是全备+归档日志的组合，都是在周末做数据库全备，每天或定时备份归档日志。这种情况一般需要的归档日志量都很大，因而会牺牲些恢复的性能。Oracle10g及之后的版本已经加入了变化块记录的机制，会大大的加快增量备份的速度，同时大大减少对应用系统性能的影响。非常建议全备份+增量备份+归档日志这样的组合。
3.4.3 需要恢复的数据文件的量
这一项很好理解，恢复一个文件当然比恢复多个文件速度快的多，做块级别恢复当然快比恢复整个数据文件的速度快的多，特别是备份介质是磁盘的情况下，恢复时要仔细分析，减少介质恢复和Recovery的量。例如，如果坏的只是一个数据文件中的几个块，可以考虑做块的介质恢复，块的恢复是在Oracle9i时开始出现的，恢复几个块而不用恢复整个文件，这样需要的基版本的备份、增量备份、归档日志都会特别的少，特别是在相应的数据文件比较大的时候，会提升恢复的速度。
3.4.4 归档日志的存在哪
如果需要的归档日志已经在磁盘上，Recovery一定会比先从
磁带备份做restore然后再做Recovery快很多，此时如果RMAN的压缩(10g开始出现)及MML压缩被使用后恢复的时间还会更长。一个好的主意就是在磁盘上存放一些近最近的归档日志，这样会加快Recovery的速度，当然这与你的备份策略及你的磁盘空间是不是允许都有关系。
3.4.5 并行恢复(10g及之后版本)
在多CPU的系统，Oracle提供了并行恢复的功能来提升Recovery的速度，特别是在大量的归档日志需要应用时。在多CPU系统做Recovery时，你可以为RECOVER命令指定一个并行度，会有多个并行进程同时工作，提升恢复的性能。
例：
RMAN> RECOVER TABLESPACE users PARALLEL 4;
4 结篇
RMAN情能调优的工作其实并不复杂，而是一个很需要劳动量的工作，这个过程中需要我们对备份、恢复策略的良好的设计，需要不断的测试。理论归理论，在实际过程中参数选为多少会达到最好的性能这是需要测试的。同时，提升RMAN性能的同时也需要做仔细的权衡，权衡其对正的生产应用产生的影响可不可以接受。RMAN性能调整也是在需求一个平衡点，使备份恢复的性能满足实际的要求，又对生产影响最小。
