RMAN 系列（九） ---- 调整RMAN备份与恢复操作的性能RMAN 系列（九） ---- 调整RMAN备份与恢复操作的性能
RMAN实际上即装即用的，我们通常不需要对其做什么调整。但是,RMAN体系结构中还包含许多组件，当这些组件构成一个整体时，就必须调整RMAN的设置以从备份进程中得到最佳的性能。通常RMAN调整设计到处理逻辑和物理数据库设计中的低效率，调整介质管理库（MediaManagementLibrary:MML）,调整RMAN和MML层以备份数据库的物理设备更好地共存。
一．调整RMAN前的工作
如果RMAN的备份操作时间非常长，这可能不是RMAN的故障。在大多数情况下，这可能是数据库或MML存在问题。关于MML请参考blog：
RMAN系列（三）----介质管理问题
https://www.doczj.com/doc/c818627134.html,/tianlesoftware/archive/2010/06/18/5678698.aspx
调整RMAN和备份与恢复进程时，也可能会出现备份时间长的问题。尽管RMAN经常出现问题，但是这并不一定是RMAN故障。可能是系统总的带宽不够，而RMAN只是造成这种局面的一个因素而已。数据库的性能越好，RMAN备份操作的性能就越好。
1.1可以达到的RMAN性能
在RMAN的白皮书上提到，在当前有效的技术条件下，在磁带备份和恢复数据的速率能够达到每小时1TB。随着磁带备份技术的不断发展，这个速率还可能变的更大。
1.2使用合适的硬件
如果想得到更高的备份性能，首先考虑的是所配置的备份硬件。备份硬件可能包括磁带设备以及关联的基础结构（如电缆，自动磁带接口和可能选用的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参数后，可以使用allocatechannel命令或configurechannel命令的parm参数来定义内存缓冲区的大小。
磁带缓冲区的大小是在配置通道时确定的，它的默认值是由操作系统决定的，不过通常为64kb。使用allocatechannel命令可以将磁带缓冲区的大小设置为不同的值。为了达到最佳性能，我们建议将磁带缓冲区的大小设置为256KB或更大。如：
Allocatechannelc1devicetypesbtparms="blksize=262144,ENV=(NB_ORA_CLASS=RMAN_orcl)"
如果要在磁盘上备份数据，我们必须判断操作系统是否支持异步I/O。如果支持，Oracle会自动使用异步I/O的功能；如果不支持，此时将Oracle提供的DBWR_IO_SLAVES参数设置为非零值，通过启动多个DBWR进程，Oracle会模拟到磁盘的异步I/O.
当配置DBWR_IO_SLAVES或者BACKUP_TAPE_IO_SLAVES时，可能也需要创建一个large池。这将帮助消除共享池争用和内存分配的错误问题，这些是在启用BACKUP_TAPE_IO_SLAVES时伴随共享池使用一起发生的问题。如果使用Oracle10g中的AutomaticSharedMemoryManagement(ASMM),Oracle将管理共享池的内存分配。如果需要手工设置large池，则磁盘缓冲区的总大小限制为每个通道16MB。为备份设置LARGE_POOL_SIZE参数的公式如下：
LARGE_POOL_SIZE=(numberofallocatedchannels)*(16MB+sizeoftapebuffer)
如果没有配置DBWR_IO_SLAVES和BACKUP_TAPE_IO_SLAVES。Rman就不会使用large池。一般来说，除非系统不支持异步I/O，这时才需要配置这些参数设置以从RMAN中获得良好的性能。
1.3调整数据库
调整欠缺的数据库也会对备份时间产生非常消极的影响。某些数据库的调整问题也会显著地影响还原时间。
1.3.1调整I/O
I/O争会降低系统的运行速度。较差的I/O分发不但会影响数据库的性能，还会影响备份和还原时间，这是因为RMAN就是在设备上争用I/O时间的另一个进程（或者并行的多个进程）。
备份是一个读密集型（read-intensive）操作。如果I/O分发较差，不仅RMAN性能会受到影响，而且用户也至少会在备份操作过程中收到影响。如果所有恢复都是完全数据库恢复，恢复操作可能会简单一点。但是如果只恢复一个数据文件或一个表空间，由于数据库被打开并处于使用当中，就能够发现较差的I/O分发会影响恢复窗口和用户。从根本上说，差的I/O分发不仅会影响日常的数据库用户，而且会导致备份和恢复操作花费更长的时间。
1.3.2调整内存的使用
与所有的Oracle进程相同，RMAN也需要使用内存。启动RMAN操作时，就会为这个Rman操作分配一个用于工作的缓冲区，我们可以根据以下因素来确定缓冲区的大小：
（1）RMAN备份和
恢复多路复用的影响
（2）所使用的设备类型
（3）操作期间所分配的通道数
1.3.2.1为磁盘设备分配内存缓冲区
在磁盘设备上备份数据时，RMAN最多可以分配16MB内存，这个内存是基于复用级别分配的。如果复用级别诶4或以下，RMAN会分配灭个大小为1MB的16个缓冲区。这些1MB缓冲区在要备份的数据文件数之间分配。因此，如果filesperset参数（设置复用级别）设置为2，每个数据文件就分配8个1MB缓冲区。
如果filesperset参数被设置为5到8之间的数，RMAN就会分配大小为512KB的缓冲区，并且均匀地分给不同的数据文件，此时，所分配的内存缓冲区不超过16MB。如果复用级别大于8，每个数据文件爱你被分配4个128kb的缓冲区，为每个数据文件分配的缓冲区总计为512KB。
1.3.2.2为SBT设备分配内存缓冲区
为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体系结构概述
https://www.doczj.com/doc/c818627134.html,/tianlesoftware/archive/2010/06/09/5659701.aspx
1.3.3调整SQL
较差的SQL语句操作会对整个数据库和数据库所在的系统产生消极的影响。任何对数据库的消极影响同样会对备份操作产生消极的影响。我们应当调整SQL操作，以减少锁需的I/O数（逻辑上和物理上），并安排在系统空闲时间执行备份操作。
1.3.4调整环境
要确认备份调度不与I/O密集型数据库操作（如数据加载或报告）冲突。另外，如果备份操作时间过长，就需要考虑使用增量备份策略，同时分析数据库并判断是否存在只读的表空间，这样就不需要经常备份只读的表空间。如果在归档模式下运行数据库，还可以考虑在不同日期交错备份表空间，以减少整个备份操作的时间，不过，这个也是以更长的恢复时间为代价的。
1.3.5调整备份和恢复策略
如果数据库相当大，我们就不能只执行一条backupdatabase命令来备份全部文件集，而应当采用分块备份策略。可以考虑使用单独的backuptablespace或者backupdatafile命令对可能需要一起还原的相关数据文件进行备份，并且为这些备份分配一个特定的通道，这样可以减少在恢复操作期间
交换磁带的次数，可以最快的恢复相关的数据文件。如：
RMAN>Backup(tablespacetoolschannel'ORA_DISK_1')(tablespacesystem,undotbs,users)
如果要备份一个稍后可能需要恢复的只读表空间，或者要经常对一个表空间执行时间点恢复操作（TSPITR）,就可以执行这样的操作，这些都是对备份策略的说明。
另一个需要考虑的就是备份策略对恢复操作的影响。其中，RMAN难以解决的一个文件，就是要使用restoredatabase命令还原一个完成的数据库。根据使用平台的不同（只针对UNIX平台，window情况不一样），必须保证有足够的空间能够用于这个还原操作。只要有足够的磁盘空间，恢复操作就不会有问题。但是一旦磁盘磁盘满了，就是一种比较糟糕的情况。
因为还原进程失败时，RMAN会删除在这个还原会话中还原的每个文件。因此，如果用户花费了2个小时还原了一个数据库数据文件之外的所有文件，而此时磁盘空间耗尽，由于RMAN要删除所有已还原的文件，所以就会前功尽弃，这对DBA来说是不能接受的。
解决这个问题的另一个方案是对每个表空间（或者几个表空间）都使用不同的restore命令，这样就可以以更小的粒度还原数据库数据文件，即使其中一个还原操作失败也不会引起更大的损失。当然，如果要使用这种操作类型，就应该并行化还原操作，并且利用多个磁盘或磁带，以减少争用和磁带流量问题。此时，需要运行并行的RMAN会话，每个RMAN会话还原各自的一组表空间数据。这种还原操作也是为什么要在同一个通道上备份还原所需的文件群集的一个另一个重要原因，这样我们可以在磁带上快速地读取数据。
刚才说磁盘满的情况是针对Unix的，如果对于window，会在启动RMAN的数据库，数据文件和表空间还原操作前检查可用的空间，这样就不会浪费时间了。
二．调整RMAN
即装即用的RMAN运行也是相当稳定的，不过还是可以调整RMAN以达到更佳的选择。
2.1调整RMAN设置
2.1.1并行通道设置
在调整数据库备份时可能施加的最大影响是使用多个RMAN通道并行化这些数据库备份。通常我们要为备份数据的每个设备都配置一个通道。因此，如果要在3个不同的磁盘上备份数据，就需要配置3个不同的通道。在同一个设备上很少存在并行化的备份操作，如果在window系统上存在D和E两个驱动器，并且这个两个驱动器是同一个磁盘的不同分区，那么在这两个驱动器上执行并行化的备份操作并不能提高速度。
为备份分配多个通常可以实现备份操的并行化，使用configure命令可以为通道配置默认值，以及决定使用多少个默认并行级别。
如，要在两个磁带设备上备份数据，就可以配置
两个默认的通道和一个默认的并行级别：
Configuredevicetypediskparallelism2;
Configurechannel1devicetypesbtformatparms'ENV=(NB_ORA_CLASS=RMAN_ORCL)';
Configurechannel2devicetypesbtformatparms'ENV=(NB_ORA_CLASS=RMAN_ORCL)';
这几条命令将确保每条backup或recover命令都自动分配两个通道来并行化备份或恢复进程。
根据使用的设备，还可以在磁盘上运行并行的数据流。调整备份多路复用会显著地影响备份和恢复性能，通常，只要不会导致来回的磁盘交换，内存越大，性能就会越佳。适当地配置多路复用会更有效地在磁带设备上传递数据流，为RMAN分配的内存越大，I/O设备上传输的数据就越多。对于新型的磁带驱动器，磁带数据流不在是一个问题，因为新的磁带驱动器通常使用大量的缓冲区内存以确保以不变的速率在磁带上写入数据。
2.1.2RMAN多路复用
多路复用（multiplexing）允许使用单个RMAN通道在备份进程期间并行读取数据库数据文件，并且将这些数据文件的内容写入同一个备份集片。因此，一个备份集片可能包含了许多不同数据文件的内容。
注意的是，某个特定数据文件的内容可以驻留在多个备份集片中。不过在某个特定的备份中，只能通过一个通道或备份集备份一个数据文件。因此，如果分配了两个通道（这样就具有两个备份集），并且数据库由一个大型数据文件组成，RMAN并行备份这个数据文件的能力会受到很大的限制。
RMAN的多路复用级别由下列两个参数中较小的参数决定。第一个参数是filesperset，才参数在执行backup命令时确定；第二个参数是maxopenfiles，该参数在分配通道时确定。
Filesperset参数确定每个备份集所包含的数据文件个数。一个备份集中的数据文件个数应当小于等于filesperset参数值。执行备份操作时，RMAN会为filesperset参数指派一个默认值，这个默认值是64，也可以输入文件数除以分配通道数的结果（取较小值）。可以通过执行带有filesperset参数命令来使用非默认的filesperset参数值，如：
Backupdatabasefilesperset4;
Maxopenfiles参数确定RMAN能够并行读取的数据文件个数（默认值是8），该参数是基于每个通道来确定的。如：
Configurechannel1devicetypediskmaxopenfiles3format'D:/backup'
如果在多个磁盘上分块备份数据，就不需要多路复用备份操作，并且可以将maxopenfiles参数设置为1.如果在很少的几个磁盘上分块备份数据，可以考虑将maxopenfiles参数设置为4到8之间的值。如果不需要分块备份数据，通常应当将maxopenfiles参数设置为8以上的值。
多路复用与filesperset参数和maxopenfiles参数的使用能够显著地影响（改善或恶化）备份操作的性能。只要系统在多路复用期间具备并行操作
的能力，调整RMAN的多路复用就可以节省备份操作所花费的时间。但如果并行度过高，也会增加系统的负担，降低备份操作的性能。
多路复用也会影响磁带操作。由于磁带系统是流设备，所以为了不断地写入数据，保持流入设备的数据流速度非常重要。通常，一旦输入磁带的数据流出现延迟，这个磁带设备在下一个写操作前停止写操作，并且重新定位写入的头，这样就会显著地影响备份操作的总性能。通常将filesperset参数设置为较大值和将maxopenfiles参数设置为较小值，这样可以调整备份数据更有效地流入磁带设备。当然，也不能太极端，以为I/O通道或CPU不支持RMAN提供的数据流量。
2.1.3控制RMAN操作的整体影响
有些时候，我们需要减低RMAN读写数据的速度。在10g之前，我们可以使用RMAN的rate和readrate来抑制RMAN读写数据的速度，释放系统资源以用于其他操作。
在10g之后，可以在backup命令中使用duration参数来控制备份的持续时间。Duration参数有一个额外的关键字minimizeload，该关键字用于指示RMAN最小化在给定持续时间内备份数据库所需的I/O负载。
如，如果一个备份需要花费5个小时，占用90%的I/O，则可以指示RMAN，使用10个小时持续时间。当minimizeload参数指示这一点时，就可以使用45%到50%的可用I/O。
Backupascopydatabaseduration10:00minimizeloaddatabase;
该命令让备份运行10个小时。当然使用duration参数的实际备份时间可能超过10个小时。任何完整的备份集都可以用于恢复，即使备份进程由于持续时间导致的问题而失败。在超出持续时间并且备份失败时，我们可以使用partial关键字取消RMAN错误。
使用duration参数时，包含最老备份的数据文件比包含日期最新RMAN备份的数据文件具有更高的优先级。比如，备份20个数据文件，若在备份完10个后失败，那么下次备份从没有备份的那10个数据文件开始备份。
2.2调整MML层
在下面的blog中对MML层有一些介绍：
RMAN系列（三）----介质管理问题
https://www.doczj.com/doc/c818627134.html,/tianlesoftware/archive/2010/06/18/5678698.aspx
对于MML备份设备来说，需要考虑很多问题。许多MML备份设备是在异步模式中运行的，但是如果MML备份设备不在异步模式中运行，就会带来很大的问题。另外，DBA偶尔会在为备份分配通道时设置rate参数，由于这些人为地导致性能瓶颈问题，所以我们通常不执行这样的操作。
一些MML供应商提供了多种可配置的参数，我们可以在供应商指定的参数文件中配置这些参数，这些参数文件为用户提供了各种调整的可能性。
与MML层有关的因素有：所有备份设备的传输速率，压缩率，数据流和数据块大小。我们必须了解这些因素，以便更
好的调整RMAN备份性能。
三．能够使用的调整视图
3.1v$session_longops和v$session视图
可以通过这2个视图来去定操作已执行时间和预计完成时间。如：
/*Formattedon2010/7/1320:04:30(QP5v5.115.810.9015)*/
SELECTa.sid,
a.serial#,
a.program,
b.opname,
b.time_remaining
FROMv$sessiona,v$session_longopsb
WHEREa.sid=b.sid
ANDa.serial#=b.serial#
ANDa.programLIKE'%rman%'
ANDtime_remaining>0;
SIDSERIAL#PROGRAMOPNAMETIME_REMAINING
---------------------------------------------------------------------
271191rman.exeRMAN:aggregateinput240
151546rman.exeRMAN:archivedlogbackup75
从这个输出，我们可以看出，连接的数据库SID为15，预计完成时间为75秒。
3.2v$backup_async_io和V$backup_sync_io视图
这两个视图分别表示RMAN异步备份和同步备份操作的详细信息。这2个视图是暂时的，并会在每次数据库关闭时被清空。这两个视图含有每个异步操作，同步操作或恢复操作的记录。其中最有用的信息是type列被设置为aggregate的记录中的effective_bytes_per_second列，该列表示每秒备份或恢复对象的字节数，这个字节数应当接近与列出的备份硬件读写速率。如果effective_bytes_per_second列中的值远小于备份硬件读写速率值，就应当查找备份进程中的问题。如：CPU超载，网络饱和，或者MML接口的配置问题。
/*Formattedon2010/7/1320:04:13(QP5v5.115.810.9015)*/
SELECTdevice_type"Device",
TYPE,
filename,
TO_CHAR(open_time,'yyyy-mm-ddhh24:mi:ss')open,
TO_CHAR(close_time,'yyyy-mm-ddhh24:mi:ss')close,
elapsed_timeet,
effective_bytes_per_secondEPS
FROMv$backup_async_io
WHEREclose_time>SYSDATE-10
ORDERBYclose_timeDESC;
DISK INPUT D:/.../SNCFORCL.ORA 2010-07-1319:27:25 2010-07-1319:27:26 100 10092544
DISK AGGREGATE 2010-07-1319:27:25 2010-07-1319:27:26 100 10092544
DISK OUTPUT D:/.../O1_MF_S_.BKP 2010-07-1319:27:25 2010-07-1319:27:26 100 10174464
DISK AGGREGATE 2010-07-1319:27:22 2010-07-1319:27:22 0
DISK INPUT D:/ARCHIVELOG/ORCL_1.ARC 2010-07-1319:27:22 2010-07-1319:27:22 0
DISK OUTPUT F:/BACKUP/ORCL1_1.BAK 2010-07-1319:27:22 2010-07-1319:27:22 0
DISK INPUT D:/.../SYSTEM01.DBF 2010-07-1319:24:46 2010-07-1319:27:17 15100 7614383
DISK AGGREGATE 2010-07-1319:24:46 2010-07-1319:27:17 15100 13711672
DISK OUTPUT F:/BACKUP/ORCL.BAK 2010-07-1319:24:46 2010-07-1319:27:17 15100 10892159
使用v$backup_async_io视图是测试备份进程效率的另一种方法。在v$backup_async_io视图中有用的几个列：
IO_COUNT:I/O计数总数
READY:缓冲区立即可用的异步I/O调用数
SHORT_WAITS:请求一个缓冲区但缓冲区不能立即使用，而以非阻塞方式轮询I/O完成之后变为可用的次数。
LONG_WAITS:请求一个缓冲区，但缓冲区不能使用，Oracle必须等待I/O设备的次数。
为了判断是否存在I/O问题，我们可以用一下代码来查看I/O和长等待的比率
（LONG_WAITS/IO_COUNT）:
/*Formattedon2010/7/1320:03:55(QP5v5.115.810.9015)*/
SELECTb.io_count,
b.ready,
b.short_waits,
b.long_waits,
b.long_waits/b.io_count,
b.filename
FROMv$backup_async_iob;
IO_COUNT READY SHORT_WAITS LONG_WAITSB.LONG_WAITS/B.IO_COUNT FILENAME
4538 3350 1138 50 0.0110180696342001
92 68 23 1 0.0108695652173913 D:/ARCHIVELOG/ORCL_1_106_719615012.ARC
92 68 23 1 0.0108695652173913 D:/ARCHIVELOG/ORCL_1_91_719615012.ARC
92 68 23 1 0.0108695652173913 D:/ARCHIVELOG/ORCL_1_99_719615012.ARC
92 68 23 1 0.0108695652173913 D:/ARCHIVELOG/ORCL_1_98_719615012.ARC
如果LONG_WAITS/IO_COUNT过高，则说明有问题。