㈠ 发现问题 RMAN在做备份、恢复时所做的操作说起来很简单: 就是把数据从“源”读到缓冲区,然后自读缓冲区写到“目的地”、并在这个过程中完成数据块的校验工作 这一过程中会发生很多的操作、而如果某一操作慢了我们则称其为瓶颈 发现问题的关键在于挑出这个瓶颈 ① 确定备份源与备份设备的最大速度 从磁盘读的速度和磁带写的带度、备份的速度不可能超出这两个速度、只能尽量的接近、我们心里要有数 Ⅰ 确定磁盘读速度: 可以在数据服务器负载高峰期做一下sar –d,把物理盘的blks/s这一列加起来,再乘上操作系统块的大小 或者 也可以挑出一些盘或LV,做对/dev/null的dd操作,然后用sar –d 进行观察,测算速度 Ⅱ 备份设备的速度 可以通过并行备份多个数据量大点的文件系统获得 ② 通过v$session_longops监测RMAN的性能 v$session_longops是一个很有用的视图,超过6秒的操作会被记录在这个视图中 这个视图观看RMAN的各个操作已经花费了多少时间,还需要多少时间,每一部分使用了多少时间
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接口的配置等几方面进行检查、优化
脚本:
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的方式,因此这个视图用的频率特别的多
脚本:
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可以通过如语句查到:
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个并行通道举例如下:
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;
㈤ 总结
RMAN 调优实则是项体力活、需要不断测试
RMAN性能调整也是在需求一个平衡点,使备份恢复的性能满足实际的要求,又对生产影响最小
分享到:
相关推荐
RMAN备份恢复性能优化--MAXSETSIZE, MAXPIECESIZE, FILESPERSET, SECTION SIZE等_ITPUB博客.mhtml
ORACLE 10g基于NFS文件系统RMAN备份优化
rman自动备份全解析及备份命令,每条命令解析详细说明
3.10 RMAN备份相关的动态性能表 15 第四篇 RMAN备份进阶 16 4.1 建立增量备份 16 4.2 建立镜像复制 18 4.3 建立冗余备份 18 4.4 设置RMAN备份的保存策略 18 4.5 备份优化 19 第五篇 RMAN备份实例 19 5.1 编写rman...
第15章 RAC稳定性与性能优化 15.1服务器硬件 15.1.1 Firmware固件升级 15.1.2硬件设备兼容性 15.1.3 FC HBA卡冗余 15.1.4 Infiniband技术 15.1.5 RAC硬件结构案例 15.2操作系统 15.2.1认证操作系统 15.2.2...
[三思笔记]一步一步学rman 一、进入rman 二、rman命令知多少 三、rman备份演练初级篇 四、rman备份演练进阶篇 五、rman外传-基础资料篇1 六、实战rman备份 七、rman外传-基础资料篇2 八、演练rman恢复 九、实战rman...
RMAN 经典 私人RMAN 经典 私人RMAN 经典 私人RMAN 经典 私人
《[三思笔记]一步一步学rman(01)-进入rman.doc》 《[三思笔记]一步一步学rman(02)-rman命令知多少.doc》 《[三思笔记]一步一步学rman(03)-rman备份演练初级篇.doc》 《[三思笔记]一步一步学rman(04)-rman备份演练...
Recovery Manager(RMAN)是一种用于备份(backup)、还原(restore)和恢复(recover) 数据库的Oracle 工具。RMAN只能用于ORACLE8或更高的版本中。它能够备份整个数据 库或数据库部件,如表空间、数据文件、控制文件、...
一、进入rman 二、rman命令知多少 三、rman备份演练初级篇 四、rman备份演练进阶篇 五、rman外传-基础资料篇1 六、实战rman备份 七、rman外传-基础资料篇2 八、演练rman恢复 九、实战rman恢复(1)丢失控制文件的恢复 ...
rman参考资料 rman参考PDF rman参考PDF rman参考PDF
【RMAN】RMAN脚本中使用替换变量--windows 下rman全备脚本【RMAN】RMAN脚本中使用替换变量--windows 下rman全备脚本【RMAN】RMAN脚本中使用替换变量--windows 下rman全备脚本
第一篇 进入RMAN 第二篇 RMAN命令知多少 第三篇 RMAN备份演练初级篇 第四篇 RMAN备份演练进阶篇 第五篇 RMAN基础知识补充 一 第六篇 实战RMAN备份 第七篇 RMAN基础知识补充 二 第八篇 演练RMAN恢复 第九篇 实战rman...
本文详细清楚地描述了oracle11g中的rman备份和恢复的所有步骤,亲测有效。
linux 平台下的rman全备份和增量备份
详细讲解了RMAN的备份机制以及如何备份
RMAN的基本配置RMAN的基本配置RMAN的基本配置RMAN的基本配置RMAN的基本配置RMAN的基本配置
Oracle Rman命令详解,包括rman命令和rman语句解析。
介绍RMAN配置,RMAN备份恢复,控制文件备份恢复,数据文件备份恢复,参数文件备份恢复,日志文件备份恢复,RMAN常用命令
内部新员工oracle培训手册-RMAN增量备份全过程-linux54-oracle112.doc