[转帖]RMAN性能调优

郑全

引言
备份是一个数据库管理员最重要的工作之一，而在一个有多个上百GB甚至N TB级数据库的企业来说，迅速、实用、稳定的备份解决方案更为重要，Oracle的RMAN工具可以满足这样的要求。RMAN是一个工具，一个不花钱且很好用的工具。

RMAN自Oracle8这个版本出现的，内嵌在Oracle RDBMS内核之中，在后续的版本中随着RDBMS的不断完善它也在不断的完善。RMAN使用起来很简单，做一些简单的设置就可以用了，DBA可以通过它很方便的完成企业内众多Oracle数据库的备份、恢复及备份的管理工作。

通常我们也不会关注RMAN的优不优化的问题，直到某一天当我们的备份或某一恢复所耗用的时间大大超出我们的预期，或者是不能满足业务逻辑的要求以及其对数据库性能产生不好的影响时，此时RMAN的调优就会摆到DBA的案头，如果这样的问题被你遇到了，有好的头绪么？本文就来说说这一方面的问题。

郑全

2 发现问题的瓶颈
RMAN在做备份、恢复时所做的操作说起来很简单，就是把数据从“源”读到缓冲区，然后自读缓冲区写到“目的地”这样的一个过程，并在这个过程中完成数据块的校验工作。这一过程中会发生很多的操作，如果而某一操作慢了我们则称其为瓶颈。调优的过程也就是找出瓶颈并处理掉的过程，当然对于RMAN的调优也是这样的。

2.1 确定备份源与备份设备的最大速度
在查找瓶颈前我们首先要对自己的设备速度心里有个数，包括从磁盘读出速度和磁带写的带度，备份的速度不可能超出这两个速度，只能尽量的接近。确定磁盘读速度可以在数据服务器负载高峰期做一下sar –d，把物理盘的blks/s这一列加起来，再乘上操作系统块的大小便可以得出速度。也可以挑出一些盘或LV，做对/dev/null的dd操作，然后用sar –d 进行观察，测算速度。 备份设备的速度可以通过并行备份多个数据量大点的文件系统获得。

2.2 通过v$session_longops监测RMAN的性能，发现瓶颈
对于DBA来说，v$session_longops是一个很有用的视图，超过6秒的操作会被记录在这个视图中。对于RMAN调优来说，这个视图更加的有用，可以通过这个视图观看RMAN的各个操作已经花费了多少时间，还需要多少时间，每一部分使用了多少时间。这对于我们发现瓶颈在哪是很有帮助的。
举例：

SQL> SELECT A.SID,
2 A.PROGRAM,
3 A.STATUS,
4 B.OPNAME,
5 b.ELAPSED_SECONDS,
6 B.TIME_REMAINING
7 FROM V$SESSION A, V$SESSION_LONGOPS B
8 WHERE A.SID = B.SID
9 AND A.SERIAL# = B.SERIAL#
10 AND upper(A.PROGRAM) LIKE '%RMAN%'
11 AND TIME_REMAINING > 0
12 /
SID PROGRAM STATUS OPNAME ELAPSED_SECONDS TIME_REMAINING
--- -------------------------- -------- ---------------------------------- --------------- -------------- 
23 RMAN@sun480-1 (TNS V1-V3) ACTIVE RMAN: incremental datafile backup 7 3
24 RMAN@sun480-1 (TNS V1-V3) ACTIVE RMAN: incremental datafile backup 12 18
2 rows selected. 

2.3 通过v$backup_sync_io和v$backup_async_io可以监测IO是否有瓶颈。
备份最主要的部分是IO操作，因此IO也是最可能产生瓶颈的地方。如果可以观察实际的备份的速率，可以观察到备份过程中的等待，这将对于我们查找哪些地方存在瓶颈大我帮助。Oracle提供了v$backup_sync_io和v$backup_async_io这两张视图用于这方面的监测。从字面意思可以看出v$backup_sync_io表现的是同步IO方式，而v$backup_async_io表现的是异步IO方式。
v$backup_sync_io和v$backup_async_io这两张视图中的数据存在的周期是实例运行的过程中。当数据库被重新启动，这两张视图中的数据会被清空。在备份、恢复过程中，每个数据文件信息、数据文件汇总信息、每一个备份片(piece)在视图中都会有一行数据。

2.3.1 同步IO瓶颈
通过如下语句查一下v$backup_sync_io视图，关注一下TYPE为AGGREGATE值的discrete_bytes_per_second这一列。这一列表示每秒中以同步方式备份、恢复数据的字节数，这个值应该接近于备份设备的读、写速率，如果这个值很小于备份设备读写速率，我们优化的机会就来了，可以从CPU负载、备份的进程、网络、MML接口的配置等几方面进行检查、优化。
脚本：

SELECT device_type device,
TYPE,
filename,
to_char(open_time,'yyyymmdd hh24:mi:ss') OPEN,
to_char(close_time,'yyyymmdd hh24:mi:ss') CLOSE,
elapsed_time elapse,
discrete_bytes_per_second d_bytes
FROM v$backup_sync_io
WHERE close_time>SYSDATE-1
ORDER BY close_time

2.3.2 异步IO瓶颈
2.3.2.1 关注每秒备份、恢复的效率
与同步IO方式有些相似，查询v$backup_async_io这张视图，不过需关注TYPE为AGGREGATE值的effective_bytes_per_second这一列，在实际的系统中，基本用的都是异步IO的方式，因此这个视图用的频率特别的多。
例：

SQL> SELECT device_type device,
2 TYPE,
3 filename,
4 to_char(open_time,'yyyymmdd hh24:mi:ss') OPEN,
5 to_char(close_time,'yyyymmdd hh24:mi:ss') CLOSE,
6 elapsed_time elapse,
7 effective_bytes_per_second e_bytes
8 FROM v$backup_async_io
9 WHERE close_time>SYSDATE-1
10 ORDER BY close_time
11 /

DEVICE TYPE FILENAME OPEN CLOSE ELAPSE E_BYTES
------ ---------- ----------------- ------ ---------- 
DISK INPUT /yang/oradata/orcl/indx01.dbf 20070924 10:16:21 20070924 10:16:22 100 26214400
DISK INPUT /yang/oradata/orcl/users01.dbf 20070924 10:16:22 20070924 10:16:22 0
DISK INPUT /u02/app/oracle/product/9.2.0/ 20070924 10:16:22 20070924 10:16:22 0
dbs/snapcf_orcl.f

DISK INPUT /yang/oradata/orcl/tools01.dbf 20070924 10:16:22 20070924 10:16:23 100 10485760
DISK INPUT /yang/oradata/orcl/users02.dbf 20070924 10:16:22 20070924 10:16:23 100 5242880
DISK AGGREGATE 20070924 10:16:21 20070924 10:16:24 300 59419307
DISK OUTPUT /yang/backup/db_incr0_63412658 20070924 10:16:21 20070924 10:16:24 300 1135957
1_91_1

DISK INPUT /yang/oradata/orcl/example01.d 20070924 10:16:21 20070924 10:16:24 300 41943040
bf

DISK AGGREGATE 20070924 10:16:22 20070924 10:16:27 500 45088768
DISK OUTPUT /yang/backup/db_incr0_63412658 20070924 10:16:22 20070924 10:16:27 500 15848243
1_92_1

DISK INPUT /yang/oradata/orcl/system01.db 20070924 10:16:22 20070924 10:16:27 500 52428800
f

DISK OUTPUT /yang/backup/db_incr0_63412658 20070924 10:16:22 20070924 10:16:27 500 27738112
1_93_1

DISK AGGREGATE 20070924 10:16:22 20070924 10:16:27 500 52753203
DISK INPUT /yang/oradata/orcl/undotbs01.d 20070924 10:16:22 20070924 10:16:27 500 41943040
bf

DISK AGGREGATE 20070924 10:16:34 20070924 10:16:34 0
DISK INPUT /yang/arch/arch1_64.arc 20070924 10:16:34 20070924 10:16:34 0
DISK OUTPUT /yang/backup/arch_634126593_94 20070924 10:16:34 20070924 10:16:34 0
_1

DISK OUTPUT /yang/backup/arch_634126593_96 20070924 10:16:34 20070924 10:16:34 0
_1

DISK INPUT /yang/arch/arch1_66.arc 20070924 10:16:34 20070924 10:16:34 0
DISK AGGREGATE 20070924 10:16:34 20070924 10:16:34 0
DISK AGGREGATE 20070924 10:16:34 20070924 10:16:35 100 31287808
DISK INPUT /yang/arch/arch1_65.arc 20070924 10:16:34 20070924 10:16:35 100 31287808
DISK OUTPUT /yang/backup/arch_634126593_95 20070924 10:16:34 20070924 10:16:35 100 31289344
_1 
23 rows selected.

SQL>

同样，当effective_bytes_per_second这一列表示每秒中以异步方式备份、恢复数据的字节数，这个值应该接近于备份设备的读、写速率，如果这个值很小于备份设备读写速率，我们优化的机会就来了，可以从备份的进程、CPU资源、网络、MML接口的配置等几方面进行检查、优化。

2.3.2.2 关注IO等待
在说这个问题之前先解释一下v$backup_async_io这张视图与IO等待相关的几列：
IO_COUNT：整个IO的总数
READY：异步方式buffer请求，buffer立即可以获复的次数。
SHORT_WAITS：请求buffer不能立即获得，不过经过简短非的阻塞方式轮询可获的次数。
LONG_WAITS： 请求buffer不能获得，需经过阻塞的等待，等待IO设备的次数。
LONG_WAIT是重点关注的对象，当LONG_WAITS/IO_COUNT这个值比较高时表明IO方式存在着瓶颈。需要注意一下相关的文件，看一下IO分布是不是存在问题。

郑全

3 RMAN性能优化
3.1 优化前的准备工作
RMAN性能优化说过来并不单纯只是RMAN的问题，这关联到要备份的数据性能如何，使用的备份设备如带库的配置是不是够用，备份策略是不是合理等许多的方面，总结起来大体如下：

3.1.1 数据库的调整
3.1.1.1　IO方面的调整
备份、恢复是一个读、写密集型的操作，因此要备份的库的数据文件的IO均衡对备份的速度影响也比较大。极限一点想，如果要备份的库的所有数据文件都放在一块磁盘上，不论如何优化，读的速度至多也就是这块盘的读速度。而相反，如果数据库在IO方面做了很好的均衡，数据文件也是跨磁盘做的条带(stripe)，不论是数据库本身，还是备份都会获得很好的性能，Oracle的测试是会有至少10%的备份性能提升。

3.1.1.2 内存方面的调整
RMAN备份过程是将数据读到buffer，然后通过MML接口写到备份设备。依数据库不同的设置，这块buffer会使用SGA区不同的部份，Oracle推荐设置合理的Large pool，让RMAN的buffer出自Large pool，关于Large pool如何设置在下面的部份会讲到。

3.1.1.3 SQL的优化
SQL的优化对于数据库本身的性能优化就起到了很关键的作用，不好的SQL会对数据库系统产生很不好的影响，耗用IO，耗用cache等各种数据库资源，调整SQL目的也是为保证数据库性能的前提下更好的提升数据的性能。

3.1.2 其它方面的准备
设置合理的备份策略，保证在业务的不繁忙期进行备份，同时做好全、增量备份的设置工作。
备份设备如带库要保证性能满足备份量的要求。
要合理的选择备份源经，比如DG环境，全备份完全可以从Standby结点来做，在不影响业务的同时也保证了备份的速度；Rac环境可以从两个结点同时来备份增加读的速度。

3.2 RMAN优化理论准备
3.2.1 并行通道(Channel Parallelism)
RMAN的备份、恢复的操作是通过通道(Channel)来完成的，Channel在数据库服务器的体现是一个Server进程。当RMAN分配一个Channel时，它即建立了一个到数据库实例的连接。在多个Channel可以相互独立的完成备份、恢复的操作，因而活动通道数即并行通道数,简而言之为并行通道。

3.2.2 多路复用(Mutiplexing)
多路复用的目的是为了加快备份时自磁盘读数据的性能，其针对的是单个channel。当单个通道在备份时，它从多个数据文件同 时读取数据，然后写到同一个备份集片(backup set)中，这样的操作模式我们称之为多路复用。
多路复用级别的多少取决于三个因素，即○1FILESPERSET参数,○2MAXOPENFILES参数○3通道读取的文件数，并最它们中的最小值。举个例子说起来就明白了，例如我的库有100个数据文件，FILESPERSET参数为12，MAXOPENFILES参数为10，那么多路复用级别=min(min(100,12),10)=10。另外需要说明的是MAXOPENFILES的默认值为16，FILESPERSET的默认值为64。

3.2.3 同/异步IO
RMAN在读数据或写数据时，所执行的IO不是同步的即为异步的。同步IO的时，服务进程在某一时点只能执行一次IO。而异步IO时，当一个服务进程在开启一次IO后，在等待这次IO完成的同时其它服务进程可以做其它的工作，也就是说它在一个时点可以执行多次IO操作。
如下以备份到带库简单描述、比较一下在同异/步备份时数据流传送的过程：

同步方式	异步方式
1、 一个服务进程写Blocks到磁带缓冲区。 2、 磁带进程写数据到磁带。在磁带设备管理器从Oracle Buffer拷数据到设备管理器内部缓冲区这段时间里，服务进程是空闲的。 3、 磁带进程写完数据后通知服务进程它完活了。 4、 服务进行再进行一个新的操作，继续从步骤1至步骤4的流程。	1、 一个服务进程写Blocks到磁带缓冲区。 2、 磁带进程写数据到磁带。在磁带进程写数据的同时，其它空闲的服务进程将更多的Blocks从读缓冲区写入到磁带缓冲区中。 3、 磁带进程不断的写，写完也不会通知服务进程。服务进程在写数据到磁带缓冲区时会触发磁带进程写数据到磁带。

郑全

.2.4 磁盘/磁带缓冲区(Buffers)
顾名思义，此时的缓冲区为缓冲备份时要传送的数据，目的是为了提升备份的性能。RMAN在备份时使用了两种类型的缓冲区，即磁盘缓冲区和磁带缓冲区。磁盘缓冲区是在读数据及写数据到磁盘备份设备时被使用的，磁带缓冲区是在执行各种磁带IO操作时被使用的。缓冲区的大小决定了单次IO所能传送数据的多少。

3.2.4.1 磁盘缓冲区
磁盘缓冲区的大小取决于多路复用(Mutiplexing)的级别，对照关系可以参数下表：

Mutiplexing	缓冲区大小
小于或等于4	每一个Buffer大小为1MB,每个数据文件4个Buffer，每个数据文件4MB*一个通道*每个通道4个文件=16M，即单个Channel缓冲区为16MB。
大于4且小于等于8	每个Buffer为512K,每个Channel的总Buffer大小最大为16M。
大于8	RMAN为每个文件分配4个固定的磁盘Buffer，每个Buffer为128K，因此每个文件会有512K的Buffer。

具体每个文件被分配了多大的Buffer可以通过如语句查到：
SELECT type, filename, buffer_size, buffer_count, open_time, close_time
FROM v$backup_async_io
ORDER by type, open_time, close_time

3.2.4.2 磁带缓冲区
当你使用带库作为备份设备，并且分配了SBT通道，Oracle会为每一个通道分配一个Buffer，每个Buffer的大小为256KB，因此每个通道的总Buffer大小为256KB*4=1024KB。
当BACKUP_TYPE_IO_SLAVES初始化数值为TRUE时，磁带缓冲区这段内存空间会从SGA区分配，如果此时也配置了LARGE_POOL_SIZE，那么磁带缓冲区会取自于LARGE POOL。当BACKUP_TYPE_IO_SLAVES初始化数值为FALSE时，磁带缓冲区会从PGA中分配。ORACLE建议这部份空间从LARGE POOL中分配，避免RMAN的IO缓冲区与Library cache的争用问题。

3.2.5 磁带驱动器相关方面
如果备份的设备是带库，磁带驱动器的多少、性能是影响RMAN的备份性能的一个很重要的因素，因此，关于磁带驱动器如下的几个方面也是很重要的。为表述方面，这时将磁带驱动器简称为带机。

3.2.5.1 本地传送速率
英文的表达为Native Transfer Speed，说白了就是带机不经过压缩每秒能备份多少数据量，表现的是带机工作性能的上限，或者说最大值。
不同厂商的带机、不同型号的带机会体现出不同的本地传送速率，例如DLT4000的本地传送速率约为1.5M/秒，而到DLT7000就达到了约5M/秒，DLT8000会有6M/秒。到现在LTO3已经成了主流，LTO2的本地传送速率为35M/秒，LTO3已经上升到了80M/秒。

3.2.5.2 磁带压缩
磁带压缩这一项对于备份的性能也是很重要的，如果有一个很好的压缩比就隐性的表明了带机更快的备份能力，以LTO2的35M为例，通常LTO的压缩比为2.3:1，此时带机便有80M/秒的备份能力。当然压缩比取决于不同厂商不同的算法，具体多少在设备的白皮书会有说明。

3.2.5.3 磁带streaming
没想好一个确切的词来表述streaming含义，有的书翻译成“数据流”，个人觉得这个词也不太恰当。Oracle用streaming这个词想表达的是带机不间断的将要备份的数据写到磁带。只所说谈及streaming是因为带机基本上是以固定的速度写数据，而当读出要备份数据的速度不及写的速度时，势必带机要停一会，然后重新启动，重新定位写入头，这些都会显著影响到RMAN备份操作总的性能。非streaming的问题经常会发现在增量备份及要备份的文件有大量的空块的情况下，在下面优化的部分还会说到这方面优化的问题。需要说明的是现在的带机通过配置大的内部缓存，在streaming方面都有了很大的改善，出现问题的机率已经很小了。

3.2.5.4 物理磁带块大小
物理磁带块大小表达的是介质管理软件一次写操作写入的数据量，这一项在实际RMAN优化中很重要，也经常用到。通常说来，大的物理磁带块大小会带来快的备份速度。不过需要注意的是，物理磁带块大小并不是受RMAN或是Oracle服务器控制，它取决于介质管理软件。加大物理磁带块大小对于改善3.2.5.3所提及的非streaming问题也很有帮助。

3.2.6 介质管理软件
上面几次提到了介质管理软件这个词，当说名词可能还有些模糊。当我们说Legato 的Networker软件、Veritas的NetBackup软件、HP的Data protector软件及Backbone等这些软件都是介质管理软件时你就明白它是什么东西了。Oracle并不直接与带库打交道，管理磁带、调动机械手等等这些介质管理工作都是由介质管理软件来完成的，Oracle通过介质管理软件提供的接口(MML)完成读、写及管理备份数据等操作。

郑全

3.3 提升备份的性能
做了如上的理论准备，实际的调优就变得轻松愉快的多了，需要注意的是我们接受或认为的良好的性能是需要多次的参数变动->测试->参数变动->测试。。这样多回次的过程，同时要权衡在追求备份性能的同时其对Oracle正常应用性能的影响，由此取一个折中点。

3.3.1 分配合理的并行通道数
分配多个并行通道会提升备份性能，但是并不是说越多越好，因此分配多少个并行通道是很重要的，要合适，不能太多也不能太少。通常的规则是，如果备份设备是带库，并行通道数不应超出带库中带机的数量；如果备份到磁盘，并行通道数不应超出磁盘子系统的数量。

实际测试表明，如果备份设备是带库，并行通道数等于带库中带机的数会达到最佳的性能，很少的情况也是一个带机分配2或3个通道达到最佳性能的状况，需要注意的是，如果并行通道数多于带机数，会出现备份集(Backup Set)在多盘磁带混合存放的情况，因而会影响到恢复的速度。如果备份到磁盘，并行通道数等于磁盘子系统的数量时会达到最佳的性能。磁盘子系统数量指的是输出设备跨几块磁盘，例如磁盘子系统分布在3块物理硬盘上，则应分配3个通道。
并行通道设置起来很简单，以配置2个并行通道举例如下：
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 2;
CONFIGURE CHANNEL 1 DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)'
CONFIGURE CHANNEL 2 DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)'

3.3.2 确定合理的“多路复用”数
多路复用体现的是一种并行，如果系统在RMAN多路复用期间还有更多的并行的能力且备份设备还有空余的能力，调整多路复用数一般都会提升备份的性能。但是这也有一个度的问题，并不是说并行程序多高越好，如果并行度过高会对数据库服务器产生影响，在降低备份服务器性能的同时也会很多的影响到备份的性能。
从实际的测试及Oracle的建议来看，多路复用设置的规则为：如果要备份的所有磁盘或数据文件很好的做了条带(stripe)，多路复用处就不大了，可以将多路复用级别设为1或者2，如果磁盘没有做条带，多路复用应当设一个8之下的一个值。大于8的值常用在备份有很多空块的文件或在做增量备份时。

3.3.3 使用异步IO
上面已经讲到了异步IO的优点，特别是向磁带设备备份时，使用异步IO就更加重要了，因为优化的一个重点就是要保证磁带的streaming。默认的情况下，当RMAN备份到磁带时使用的是同步IO，同步IO在一个时点只能执行一次操作，此时的备份性能一定是很糟的，而异步IO一个时点可以做多次操作，更好的填充写缓冲区，保证磁带的streaming。对于支持本地异步IO的系统，启用比较简单,BACKUP_TAPE_IO_SLAVES这个初始化参数设为TRUE就可以了。

3.3.4 当备份设备为带库时，以BLKSIZE参数调整磁带缓冲区
当备到磁带时，这是改善RMAN备份性能很重要的一项，通常说来，大的物理磁带块大小会带来快的备份速度。RMAN通道的BLKSIZE参数确定了磁带缓冲区的大小，实际的测试及Oracle的建议都表明磁带缓冲区至少应为256K，在Oracle8i时这个值的默认值为64KB，在Oracle9i中256KB已经是默认值了。
如果你的磁带备份出现了Not Streaming问题，经过检查发现问题的并不是出现在备份空文件及做增量备份上，你可以尝试调整BLKSIZE参数来改变磁带缓冲区，Not Streaming会有改善。
改变BLKSIZE参数也很简单，调整ALLOCATE CHANNEL或CONFIGURE CHANNEL的PARAM参数即可。例如，可以这样将磁带缓冲区设成512K：
RMAN>configure channel device type sbt PARAMS= “BLKSIZE=524288 ”

3.3.5 设定合理的LARGE_POOL_SIZE值
如果LARGE_POOL_SIZE参数没有设定，磁盘及磁带缓冲区会试图从shared pool中分配，这样会引起shared pool中各组件如Library cache的争用问题，对生产库及备份的性能产生影响。相反，设定了LARGE_POOL_SIZE参数，磁盘及磁带缓冲区便会出自LARGE POOL。LARGE POOL要分配一个合理值，如果其大小不够用，磁盘及磁带缓冲区会从本地进程的内存中分配，同时Oracle会在alert log写入如下的警告信息：
Ksfqxcre: failure to allocate chared memory means sync I/O will be used whenever async I/O to file not supported natively
LARGE POOL大小至少该为多大呢？Oracle给出了如下的计算公式：
Oracle 8I:
LARGE_POOL_SIZE=(4*分配的通道数*DB_BLOCK_SIZE*复用级别)+(4*分配的通道数*磁带缓冲区大小)
Oracle 9I：
LARGE_POOL_SIZE=分配的通道数*(16M+4*磁带缓冲区大小)

3.3.6 空文件及增量备份时需考虑的问题
当备份包含大量空块的文件及做增量备份时，保证磁带缓冲区满是一件较难的事，因而会引起磁带的Not Sreaming的问题。这方面的优化说起来也很容易，此时可以将多路复用(Multiplexing)调整到一个比较大的值，比如50。

郑全

。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性能调整也是在需求一个平衡点，使备份恢复的性能满足实际的要求，又对生产影响最小。