【引言】
一个实际生产案例,因数据库数据量的增大,全备需68个小时,增备也需11小时。此场景下,如发生需要库恢复的场景,所需时长基本不能忍受,鉴于如下之前的两篇文章,使用dataguard 的delay参数做了24小时的日志延迟应用,可确保24小时内的任意恢复,大大缩短了异常时恢复数据的时间。
《ADG实操:如何吃下这颗“后悔药”》
《Oracle ADG同步技术,DBA必备的一种“后悔药”》
但本文想讨论的是:有什么方法可以缩短全备或者增备的时长?
为实现缩短备份时长,这里先介绍三种常用的备份方式:
一、 几种常用库备份方式:
目前数据备份主要方式有:Host-Base、LAN-Base、LAN Free备份和SAN Server-Free备份四种方式。
-
Host-Based备份:
Host-Based是传统的数据备份方式,磁带库直接接在服务器上,且通常只为该服务器提供数据备份服务。这种备份大多是采用服务器上自带的磁带机,备份操作通过手工操作调用。
Host-Based备份结构的优点是数据传输速度快,备份操作简单;缺点是不利于备份系统的共享,不适合于现在大型的数据备份要求。 -
LAN-Based备份:
LAN-Based备份方式,数据的传输是以网络为基础的。首先配置一台服务器作为备份服务器,磁带库则接在某台服务器上。数据备份时备份对象把数据通过网络传输到磁带库中实现备份。
LAN-Based备份结构的优点是磁带库共享,备份可集中管理;缺点是库备份时对网络传输压力太大,不适合数据量非常大的环境。因为如果备份数据量非常大,会占用以太网的带宽,虽然说备份操作一般在晚上进行。但是这种方式还是不适合大数据量的情况。因此有了LAN free备份。
3.LAN-Free备份:
Lan free,释放了LAN的压力。数据流直接从File server经过FC switch备份到Tape,而不经过Lan,不会占用主网络的带宽。但数据仍然会通过文件服务器的本地磁盘–内存—FC switch这步,因此仍然会消耗File server的资源。因此有了下面的Server Free备份来尽可能的减少生产服务器的压力。
LAN-Free的优点是数据备份统一管理、备份速度快、网络传输压力小、磁带库资源共享;缺点是投资高。利用IBM Tivoly Storage Manager软件,配合IBM LTO等磁带库产品,可以实现以上各种备份方式。
- Server-Free备份
LAN Free备份需要占用备份主机的CPU资源,如果备份过程能够在SAN内部完成,而大量数据流无需流过服务器,则可以极大降低备份操作对生产系统的影响。SAN Server-Free备份就是这样的技术。
server free,即备份时数据不流经服务器的总线和内存,文件服务器使用SAN的File Server Storage空间,只需将File Server Storage的数据直接备份到Tape。此时文件服务器只需要发出SCSI扩展复制命令,剩下的事情就是File Server Storage和Tape之间的事情了,这样就减轻了文件服务器的很多压力,使它可以专注于对外提供文件服务,而不需要再消耗大量CPU、内存、IO在备份的事情上了。
【小结】
LAN 备份针对所有存储类型都可以使用, LAN-Free和Server-Free的备份系统是建立在SAN(存储区域网)的基础上,基于SAN的备份是一种解决传统备份方式需要占用LAN带宽问题的解决方案。
目前主流的备份软件,如IBM Tivoli 、Veritas,均支持上述种LAN-Base、LAN Free、SAN Server-Free备份方式。三种方案中,LAN备份数据量最小,对服务器资源占用最多,成本最低;LAN free备份数据量大一些,对服务器资源占用小一些,成本高一些;SAN Server-free备份方案能够在短时间备份大量数据,对服务器资源占用最少,但成本最高。
综合考虑,使用lan-free方案较为适中,实际生产中也以IBM Tivoli的LAN free做了备份优化。全备从68小时降低为18小时,增备有11小时降低为3小时。
这里再介绍下Tivoli Storage Manager LAN-free 备份步骤:
- Backup-Archive Client 开始一个备份操作. Tivoli Storage Manager server
报告策略信息给 client, 其中的策略信息包括一个目的地是否是 LAN-free enabled的. 在备份过程中,client将根据策略设置分配文件, 当该策略的目的地的属性是LAN-free enabled的,它将使用 Storage Agent通过LAN-free方式来发送数据。 - Storage Agent 接收由client传送的要备份的文件数据,根据策略设置作相应分配, 然后,Storage Agent 发送一个volume mount请求给 Library Manager server.
3.从 Library Manager发送 一个请求到 storage device ,要求mount 相应的media. - Library Manager 通知 Storage Agent ,mounted media所在的具体位置。
- client 通过 Storage Agent, 把备份数据直接通过SAN方式写到目标设备上。
- Storage Agent 发送元数据(metadata)信息给Tivoli Storage Manager server 通过
LAN方式, server 把这些信息保存到TSM database.
看到这里,抛出一个问题:备份过程还有优化的空间吗?
这时大家也会有个疑问:文不符题啊,题目明明是“如何提速oracle增备_块跟踪备份”
全备基本没什么优化空间,但增备还是有的,那就是开启快跟踪BLOCK CHANGE TRACKING。
复习下块跟踪:
1. 通过位图跟踪两次备份间变化的数据块;
2. 每次备份前进行位图切换;
3. 开发增量备份策略时,要考虑到8个位图的限制;
4. 在RAC环境中,change tracking file需要放在共享存储上;
5. Change tracking file的大小和数据库的大小、enabled的redo thread的个数成正比;
6. Change tracking file的大小和数据更新的频率无关;
如何开启快跟踪?
很简单,在mount或open状态下enable change tracking;
1.检查change tracking状态
sql> SELECT STATUS, FILENAME FROM V$BLOCK_CHANGE_TRACKING;
2.Enable change tracking
sql>ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE ‘/mydir/rman_change_track.f’ REUSE;
3.Disable change tracking
sql>ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
如果想改变change tracking file的位置,两种方法:
方法1:不关闭数据库的方式
SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE ‘new_location’;
注意:这种方式会丢失change tracking file的内容
方法2:关闭数据库的方式
SQL> SELECT FILENAME FROM V$BLOCK_CHANGE_TRACKING;(确定当前的文件名)
SQL> SHUTDOWN IMMEDIATE
用操作系统命令将文件move到新路径
SQL> ALTER DATABASE RENAME FILE
‘/disk1/changetracking/rman_change_track.f’ TO
‘/disk2/changetracking/rman_change_track.f’;
SQL> ALTER DATABASE OPEN;
【结语】
1.本文介绍了Host-Base、LAN-Base、LAN Free备份和SAN Server-Free四种备份方式;
2.在备份方式确定的情况下,使用oracle的快跟踪来提升增备的速度,根据实际生产效果,增备速度有原来的耗时3小时减少至1.7小时。
【参考】
http://blog.sina.com.cn/s/blog_548dcecc0101r14p.html
【参考】
https://www.cnblogs.com/Study-Blog/p/8649922.html
关注个人微信公众号;
长按以下二维码或公众号搜索“一森咖记”