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,
同样，当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分布是不是存在问题。
