RMAN性能优化全攻略
㈠ 发现问题
RMAN在做备份、恢复时所做的操作说起来很简单：
就是把数据从“源”读到缓冲区，然后自读缓冲区写到“目的地”、并在这个过程中完成数据块的校验工作
这一过程中会发生很多的操作、而如果某一操作慢了我们则称其为瓶颈
发现问题的关键在于挑出这个瓶颈
① 确定备份源与备份设备的最大速度
从磁盘读的速度和磁带写的带度、备份的速度不可能超出这两个速度、只能尽量的接近、我们心里要有数
Ⅰ 确定磁盘读速度：
可以在数据服务器负载高峰期做一下sar –d，把物理盘的blks/s这一列加起来，再乘上操作系统块的大小
或者
也可以挑出一些盘或LV，做对/dev/null的dd操作，然后用sar –d 进行观察，测算速度
Ⅱ 备份设备的速度
可以通过并行备份多个数据量大点的文件系统获得
② 通过v$session_longops监测RMAN的性能
v$session_longops是一个很有用的视图，超过6秒的操作会被记录在这个视图中
这个视图观看RMAN的各个操作已经花费了多少时间，还需要多少时间，每一部分使用了多少时间
[sql]
sys@ORCL> ed
Wrote file afiedt.buf
1 SELECT A.SID,A.PROGRAM,A.STATUS,B.OPNAME,B.ELAPSED_SECONDS,B.TIME_REMAINING
2 FROM V$SESSION A, V$SESSION_LONGOPS B
3 WHERE A.SID = B.SID AND
4 A.SERIAL# = B.SERIAL# AND
5 upper(A.PROGRAM) LIKE '%RMAN%' AND
6* TIME_REMAINING > 0
③ 通过v$backup_sync_io和v$backup_async_io可以监测IO是否有瓶颈
备份最主要的部分是IO操作，因此IO也是最可能产生瓶颈的地方
Oracle提供了v$backup_sync_io和v$backup_async_io这两张视图用于：
观察实际的备份的速率、观察备份过程中的等待
这两张视图中的数据存在的周期是实例运行的过程中、当数据库被重新启动，这两张视图中的数据会被清空
⑴ 同步IO瓶颈
查询v$backup_sync_io视图、关注TYPE为AGGREGATE值的discrete_bytes_per_second这一列
这一列表示每秒中以同步方式备份、恢复数据的字节数，这个值应该接近于备份设备的读、写速率
如果这个值很小于备份设备读写速率，我们优化的机会就来了
可以从CPU负载、备份的进程、网络、MML接口的配置等几方面进行检查、优化
脚本：
[sql]
sys@ORCL> ed
Wrote file afiedt.buf
1 SELECT device_type device,TYPE,filename,
2 to_char(open_time,'yyyymmdd hh24:mi:ss') OPEN,
3 to_char(close_time,'yyyymmdd hh24:mi:ss') CLOSE,
4 elapsed_time elapse,discrete_bytes_per_second d_bytes
5 FROM v$backup_sync_io
6 WHERE close_time>SYSDATE-1
7* ORDER BY close_time
⑵ 异步IO瓶颈
Ⅰ 关注每秒备份、恢复的效率
查询v$backup_async_io、关注TYPE为AGGREGATE值的effective_bytes_per_second这一列
在生产环境，基本用的都是异步IO的方式，因此这个视图用的频率特别的多
脚本：
[sql]
sys@ORCL> ed
Wrote file afiedt.buf
1 SELECT device_type device,TYPE,filename,
2 to_char(open_time,'yyyymmdd hh24:mi:ss') OPEN,
3 to_char(close_time,'yyyymmdd hh24:mi:ss') CLOSE,
4 elapsed_time elapse,effective_bytes_per_second e_bytes
5 FROM v$backup_async_io
6 WHERE close_time>SYSDATE-1
7* ORDER BY close_time
同理、当effective_bytes_per_second这一列表示每秒中以异步方式备份、恢复数据的字节数
这个值应该接近于备份设备的读、写速率，如果这个值很小于备份设备读写速率、我们也该注意了
Ⅱ 关注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分布是不是存在问题
㈡ 优化前的准备工作
⑴ 战略上
① IO方面的调整
备份、恢复是一个读、写密集型的操作
数据文件的IO均衡对备份的速度影响极大
如果数据库在IO方面做了很好的均衡，数据文件也是跨磁盘做的条带(stripe)
Oracle的测试是会有至少10%的备份性能提升
② 内存方面的调整
RMAN备份过程是将数据读到buffer，然后通过MML接口写到备份设备
Oracle推荐设置合理的Large pool，让RMAN的buffer出自Large pool
③ SQL的优化
不好的SQL耗用IO，耗用cache等各种数据库资源
这会让RMAN可用资源减小
④ 备份策略的调整
