频道栏目
首页 > 数据库 > Oracle > 正文
RMAN性能优化全攻略
2013-04-13 14:17:14           
收藏   我要投稿

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可用资源减小

         

      ④ 备份策略的调整

         

         在业务的不繁忙期进行备份,同时做好全、增量备份的设置工作

         比如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)的级别,对照关系可以参数下表:

 

 

            具体每个文件被分配了多大的Buffer可以通过如语句查到:

 

[sql] 

sys@ORCL> ed  

Wrote file afiedt.buf  

  

  1  SELECT type, filename, buffer_size, buffer_count, open_time, close_time  

  2    FROM v$backup_async_io  

  3*  ORDER by type, open_time, close_time  

 

 

         Ⅱ 磁带缓冲区

            

            当你使用带库作为备份设备,并且分配了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个并行通道举例如下:

 

[sql] 

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: 

 

[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性能调整也是在需求一个平衡点,使备份恢复的性能满足实际的要求,又对生产影响最小

 

点击复制链接 与好友分享!回本站首页
相关TAG标签 全攻略 性能
上一篇:一个菜鸟的oracle之路----------三
下一篇:重现Oracle数据库Hang住的情况
相关文章
图文推荐
点击排行

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站