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、 磁带进程不断的写，写完也不会通知服务进程。服务进程在写数据到磁带缓冲区时会触发磁带进程写数据到磁带。