怎样为Tsm备份提速？

RMAN性能优化全攻略
1、 发现问题

  Ⅰ 确定磁盘读速度：
  可以在数据服务器负载高峰期做一下sar –d，把物理盘的blks/s这一列加起来，再乘上操作系统块的大小
  或者
  也可以挑出一些盘或LV，做对/dev/null的dd操作，然后用sar –d 进行观察，测算速度
  Ⅱ 备份设备的速度
  可以通过并行备份多个数据量大点的文件系统获得

② 通过v$session_longops监测RMAN的性能

  v$session_longops是一个很有用的视图，超过6秒的操作会被记录在这个视图中
  这个视图观看RMAN的各个操作已经花费了多少时间，还需要多少时间，每一部分使用了多少时间

③ 通过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接口的配置等几方面进行检查、优化
     脚本： 

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可用资源减小
  ④ 备份策略的调整
     在业务的不繁忙期进行备份，同时做好全、增量备份的设置工作
     比如DG环境，全备份完全可以从Standby结点来做，在不影响业务的同时也保证了备份的速度
     Rac环境可以从两个结点同时来备份增加读的速度

⑵ 战术上

  ① 并行通道(Channel Parallelism)
     RMAN的备份、恢复的操作是通过通道(Channel)来完成的
     Channel在数据库服务器的体现是一个Server进程
     当RMAN分配一个Channel时，它即建立了一个到数据库实例的连接
     多个Channel可以相互独立的完成备份、恢复的操作
     因而活动通道数即并行通道数,简而言之为并行通道
  ② 多路复用(Mutiplexing) 
     多路复用的目的是为了加快备份时自磁盘读数据的性能，其针对的是单个channel
     当单个通道在备份时，它从多个数据文件同时读取数据，然后写到同一个backupset中
     这样的操作模式我们称之为多路复用
     多路复用级别的多少取决于三个因素：
     ● FILESPERSET参数
     ● MAXOPENFILES参数
     ● 通道读取的文件数
     例如我的库有100个数据文件，FILESPERSET参数为12，MAXOPENFILES参数为10
     那么多路复用级别=min(min(100,12),10)=10
  ③ 同/异步IO

比较一下在同异/步备份时数据流传送的过程

   ④ 磁盘/磁带缓冲区(Buffers) 
     缓冲区的大小决定了单次IO所能传送数据的多少
     Ⅰ 磁盘缓冲区 
        磁盘缓冲区的大小取决于多路复用(Mutiplexing)的级别
     Ⅱ 磁带缓冲区
        当你使用带库作为备份设备，并且分配了SBT通道，Oracle会为每一个通道分配一个Buffer
        当BACKUP_TYPE_IO_SLAVES初始化数值为TRUE时，磁带缓冲区这段内存空间会从SGA区分配
        当BACKUP_TYPE_IO_SLAVES初始化数值为FALSE时，磁带缓冲区会从PGA中分配
        ORACLE建议这部份空间从LARGE POOL中分配，避免RMAN的IO缓冲区与Library cache的争用问题
  ⑤ 磁带自身的情况
     每家厂商每种产品的带机都有其利弊

㈢ 提升备份的性能
① 分配合理的并行通道数

  实际测试表明，如果备份设备是带库，并行通道数等于带库中带机的数会达到最佳的性能
  很少的情况也是一个带机分配2或3个通道达到最佳性能的状况
  需要注意的是，如果并行通道数多于带机数，会出现Backupset在多盘磁带混合存放的情况
  因而会影响到恢复的速度
  如果备份到磁盘，并行通道数等于磁盘子系统的数量时会达到最佳的性能
  磁盘子系统数量指的是输出设备跨几块磁盘
  例如磁盘子系统分布在3块物理硬盘上，则应分配3个通道
  并行通道设置起来很简单，以配置2个并行通道举例如下：

CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 2;
CONFIGURE CHANNEL 1 DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)';
CONFIGURE CHANNEL 2 DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)';
② 确定合理的“多路复用”数

  从实际的测试及Oracle的建议来看，多路复用设置的规则为：
  如果要备份的所有磁盘或数据文件很好的做了条带(stripe)，多路复用处就不大了，可以将多路复用级别设为1或者2
  如果磁盘没有做条带，多路复用应当设一个8之下的一个值
  大于8的值常用在备份有很多空块的文件或在做增量备份时

③ 使用异步IO

  默认的情况下，当RMAN备份到磁带时使用的是同步IO
  同步IO在一个时点只能执行一次操作，此时的备份性能一定是很糟的
  而异步IO一个时点可以做多次操作，更好的填充写缓冲区，保证磁带的streaming
  对于支持本地异步IO的系统，启用比较简单,BACKUP_TAPE_IO_SLAVES这个初始化参数设为TRUE就可以了

④ 当备份设备为带库时，以BLKSIZE参数调整磁带缓冲区

  当备到磁带时，这是改善RMAN备份性能很重要的一项
  RMAN通道的BLKSIZE参数确定了磁带缓冲区的大小
  实际的测试及Oracle的建议都表明磁带缓冲区至少应为256K
  如果你的磁带备份出现了Not Streaming问题，经过检查发现问题的并不是出现在备份空文件及做增量备份上
  你可以尝试调整BLKSIZE参数来改变磁带缓冲区，Not Streaming会有改善
  改变BLKSIZE参数也很简单，调整ALLOCATE CHANNEL或CONFIGURE CHANNEL的PARAM参数即可
  例如，可以这样将磁带缓冲区设成512K： 

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 警告信息：

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命令指定一个并行度，会有多个并行进程同时工作
  例如：

RMAN> RECOVER TABLESPACE users PARALLEL 4;
仅供参考