，我们通常不需要对其做什么调整。 但是,RMAN 体系结构中还包含许多组件，当这些组件构成一个整体时，就必须调整RMAN的设置以从备份进程中得到最佳的性能。 通常RMAN 调整设计到处理逻辑和物理数据库设计中的低效率，调整介质管理库（Media Management Library: MML）, 调整RMAN 和MML 层以备份数据库的物理设备更好地共存。
如果RMAN 的备份操作时间非常长，这可能不是RMAN的故障。 在大多数情况下，这可能是数据库或MML存在问题。 关于MML 请参考blog：
RMAN 系列（三） ---- 介质管理问题
调整RMAN和备份与恢复进程时，也可能会出现备份时间长的问题。尽管RMAN经常出现问题，但是这并不一定是RMAN故障。可能是系统总的带宽不够，而RMAN 只是造成这种局面的一个因素而已。 数据库的性能越好，RMAN 备份操作的性能就越好。
在RMAN 的白皮书上提到，在当前有效的技术条件下，在磁带备份和恢复数据的速率能够达到每小时1TB。 随着磁带备份技术的不断发展，这个速率还可能变的更大。
如果想得到更高的备份性能，首先考虑的是所配置的备份硬件。 备份硬件可能包括磁带设备以及关联的基础结构（如电缆， 自动磁带接口 和 可能选用的MML层软件）。
备份介质硬件决定了读写设备的速度。 写设备的速度越快，备份的速度就会越快。 此外，执行备份操作的设备越多，备份速度也就会越快。 增加RMAN使用驱动器几乎能够线性地提高备份和还原操作的效率。 在多个通道和备份设备中并行执行备份操作的能力对于快速备份大型Oracle 数据库是至关重要的。
RMAN能够受益于并行的CPU 资源，但是仅限于此而已，再增加更多的CPU 并不会继续使性能显著提高。 这与使用更多的备份设备是完全不同的。 在大多数情况下，使用多个备份设备比添加CPU更能够对备份和还原窗口产生积极的影响。
异步设备使得备份服务器进程无需等待I/O 的完成就可以发出I/O指令。例如：允许服务器进程发出磁盘写指令，在执行这个指令的同时，该进程可以继续填充内存缓冲区以准备下一个写操作。 另一方面，在执行其他任何工作之前都必须等待备份操作的完成。 因此，
下面说几个有关异步操��的参数：
BACKUP_TAPE_IO_SLAVES参数（默认为False）是设置磁带I/O异步的。如果支持磁带备份设备的异步I/O，我们建议将这个参数设置为TRUE，以启动该设置。 建立BACKUP_TAPE_IO_SLAVES参数后，可以使用allocate channel命令或configure channel 命令的parm 参数来定义内存缓冲区的大小。
磁带缓冲区的大小是在配置通道时确定的，它的默认值是由操作系统决定的，不过通常为64kb。 使用allocate channel命令可以将磁带缓冲区的大小设置为不同的值。 为了达到最佳性能，我们建议将磁带缓冲区的大小设置为256KB 或更大。 如：
Allocate channel c1 device type sbt parms="blksize=262144, ENV=(NB_ORA_CLASS=RMAN_orcl)"
如果的功能；如果，Oracle 会模拟到磁盘的异步I/O.
这将帮助消除共享池争用和内存分配的错误问题，这些是在启用BACKUP_TAPE_IO_SLAVES时伴随共享池使用一起发生的问题。如果使用Oracle 10g中的Automatic Shared Memory Management(ASMM),Oracle 将管理共享池的内存分配。 如果需要手工设置large 池，则磁盘缓冲区的总大小限制为每个通道16MB。 为备份设置LARGE_POOL_SIZE参数的公式如下：
LARGE_POOL_SIZE=(number of allocated channels)*(16MB+size of tape buffer)
。一般来说，除非系统不支持异步I/O，这时才需要配置这些参数设置以从RMAN中获得良好的性能。
调整欠缺的数据库也会对备份时间产生非常消极的影响。 某些数据库的调整问题也会显著地影响还原时间。
I/O 争会降低系统的运行速度。较差的I/O分发不但会影响数据库的性能，还会影响备份和还原时间， 这是因为RMAN就是在设备上争用I/O时间的另一个进程（或者并行的多个进程）。
备份是一个读密集型（read-intensive）操作。 如果I/O 分发较差，不仅RMAN性能会受到影响，而且用户也至少会在备份操作过程中收到影响。 如果所有恢复都是完全数据库恢复，恢复操作可能会简单一点。 但是如果只恢复一个数据文件或一个表空间，由于数据库被打开并处于使用当中，就能够发现较差的I/O分发会影响恢复窗口和用户。 从根本上说，差的I/O 分发不仅会影响日常的数据库用户， 而且会导致备份和恢复操作花费更长的时间。
与所有的Oracle 进程相同，RMAN 也需要使用内存。 启动RMAN操作时，就会为这个Rman操作分配一个用于工作的缓冲区，我们可以根据以下因素来确定缓冲区的大小：
（1） RMAN 备份和恢复多路复用的影响
（2） 所使用的设备类型
（3） 操作期间所分配的通道数
在磁盘设备上备份数据时， 如果复用级别诶4或以下，RMAN 会分配灭个大小为1MB的16个缓冲区。这些1MB缓冲区在要备份的数据文件数之间分配。 因此，如果filesperset 参数（设置复用级别）设置为2，每个数据文件就分配8个1MB缓冲区。
如果filesperset参数被设置为5到8之间的数，RMAN 就会分配大小为512KB的缓冲区，并且均匀地分给不同的数据文件，此时，所分配的内存缓冲区不超过16MB。 如果复用级别大于8，每个数据文件爱你被分配4个128kb的缓冲区，为每个数据文件分配的缓冲区总计为512KB。
为SBT设备上备份数据时，RMAN会为所分配的每个通道分配4个缓冲区。 这些缓冲区的大小通常为256kb，因此每个通道分配的总内存为1MB。 可以使用allocate 或send 命令的parms 和blkzise 参数管理缓冲区大小。
这个内存通常是从PGA中分配的，不过如果BACKUP_TAPE_TO_SLAVES参数被设置为TRUE，除非分配了large池，否则就需要使用SGA，在这种情况下要使用large池。 因此，如果要配置I/O从属（在SBT设备上备份数据时通常应当配置I/O从属），就应当配置一个large池，以减少large池对整个内存的需求。
在下面的这边blog中第8节，内存中的RMAN 也提到了以上信息，可以参考：
RMAN 系列（一）---- RMAN 体系结构概述
较差的SQL语句操作会对整个数据库和数据库所在的系统产生消极的影响。任何对数据库的消极影响同样会对备份操作产生消极的影响。 我们应当调整SQL 操作， 以减少锁需的I/O数（逻辑上和物理上），并安排在系统空闲时间执行备份操作。
要确认备份调度不与I/O密集型数据库操作（如数据加载或报告）冲突。另外，如果备份操作时间过长，就需要考虑使用增量备份策略，同时分析数据库并判断是否存在只读的表空间，这样就不需要经常备份只读的表空间。 如果在归档模式下运行数据库，还可以考虑在不同日期交错备份表空间，以减少整个备份操作的时间， 不过，这个也是以更长的恢复时间为代价的。
如果数据库相当大，我们就不能只执行一条backup database命令来备份全部文件集，而应当采用分块备份策略。 可以考虑使用单独的backup tablespace 或者backup datafile命令对可能需要一起还原的相关数据文件进行备份，并且为这些备份分配一个特定的通道，这样可以减少在恢复操作期间交换磁带的次数，可以最快的恢复相关的数据文件。 如：
RMAN>Backup (tablespace tools channel 'ORA_DISK_1') (tablespace system,undotbs,users)
如果要备份一个稍后可能需要恢复的只读表空间，或者要经常对一个表空间执行时间点恢复操作（TSPITR）,就可以执行这样的操作， 这些都是对备份策略的说明。
另一个需要考虑的就是备份策略对恢复操作的影响。 其中，RMAN难以解决的一个文件，就是要使用restore database命令还原一个完成的数据库。 根据使用平台的不同（只针对UNIX 平台，window 情况不一样），必须保证有足够的空间能够用于这个还原操作。 只要有足够的磁盘空间，恢复操作就不会有问题。 但是一旦磁盘磁盘满了，就是一种比较糟糕的情况。
因此，如果用户花费了2个小时还原了一个数据库数据文件之外的所有文件，而此时磁盘空间耗尽，由于RMAN要删除所有已还原的文件，所以就会前功尽弃，这对DBA来说是不能接受的。
解决这个问题的另一个方案是对每个表空间（或者几个表空间）都使用不同的restore命令，这样就可以以更小的粒度还原数据库数据文件，即使其中一个还原操作失败也不会引起更大的损失。 当然，如果要使用这种操作类型，就应该并行化还原操作，并且利用多个磁盘或磁带，以减少争用和磁带流量问题。 此时，需要运行并行的RMAN会话，每个RMAN 会话还原各自的一组表空间数据。 这种还原操作也是为什么要在同一个通道上备份还原所需的文件群集的一个另一个重要原因，这样我们可以在磁带上快速地读取数据。
刚才说磁盘满的情况是针对Unix的，如果对于Windows，会在启动RMAN 的数据库，数据文件和表空间还原操作前检查可用的空间，这样就不会浪费时间了。