RMAN性能优化全攻略(三)
LKSIZE参数也很简单，调整ALLOCATE CHANNEL或CONFIGURE CHANNEL的PARAM参数即可
例如，可以这样将磁带缓冲区设成512K：
[sql]
RMAN>configure channel device type sbt PARAMS= “BLKSIZE=524288 ”
⑤ 设定合理的LARGE_POOL_SIZE值
如果LARGE_POOL_SIZE参数没有设定，磁盘及磁带缓冲区会试图从shared pool中分配
这样会引起shared pool中各
组件如Library cache的争用问题
LARGE POOL要分配一个合理值，如果其大小不够用，磁盘及磁带缓冲区会从PGA分配，同时alert 警告信息：
[sql]
Ksfqxcre: failure to allocate chared memory means sync I/O will be used whenever async I/O to file not supported natively
⑥ 空文件及增量备份时需考虑的问题
当备份包含大量空块的文件及做增量备份时，保证磁带缓冲区满是一件较难的事，因而会引起磁带的Not Sreaming的问题
这方面的优化说起来也很容易，此时可以将多路复用(Multiplexing)调整到一个比较大的值，比如50
㈣ 提升恢复的性能
① 数据库的性能
● I/O
Recovery是一个读和写都密集型的操作，它需要：
读出归档日志的内容
把数据文件相关的blocks读到Cache
把Recover完的脏块回写到硬盘
因此数据库要有良的IO均衡和良好的IO性能
● DBWR的性能
Recovery过程中的脏块回写到数据文件的工作是由DBWR进程来完成的
因此DBWR的性能也会对Recovery的性能产生影响
DBWR的瓶颈可以通过v$session_wait视图的”free buffer waits”表现出来
如果在各个时点总有一些这样的等待说明DBWR的写速度存在着瓶颈
提高DBWR写速度的方法有：
启用异步IO
多加一个DBWR进程
● CPU的性能
每一个需要recover的数据块在重做日志应用其上前首先要被读入Buffer cache中
因此这便有一个栓(Latch)获取的过程，包括cache buffers chains和cache buffers lru chain两种栓
获取栓对数据块修改的过程都需要CPU资源
因此在Recovery过程中要确保有充足的CPU带宽，特别是在做并行Recovery的时候
② 恢复要需用到的归档日志、增量备份的量
理论及实测都表明，增量备份会加快数据恢复的速度，用到的归档量越多恢复的时间会越加长
10g及之后的版本已经加入了变化块记录的机制，会大大的加快增量备份的速度，同时大大减少对应用
系统性能的影响
③ 需要恢复的数据文件的量
恢复时要仔细分析，减少介质恢复和Recovery的量
例如，如果坏的只是一个数据文件中的几个块，可以考虑做块的介质恢复
④ 归档日志的存在哪
一个好的主意就是在磁盘上存放一些近最近的归档日志，这样会加快Recovery的速度
⑤ 并行恢复(10g及之后版本)
在多CPU系统做Recovery时，你可以为RECOVER命令指定一个并行度，会有多个并行进程同时工作
例如：
[sql]
RMAN> RECOVER TABLESPACE users PARALLEL 4;
㈤ 总结
RMAN 调优实则是项体力活、需要不断测试
RMAN性能调整也是在需求一个平衡点，使备份恢复的性能满足实际的要求，又对生产影响最小