利用块跟踪来缩短增量备份时间

作者:八神 | 分类: 大话技术 | 标签: | 日期:2008-03-01

        oracle提供增量备份数据库的功能,这个功能的大致原理就是根据上次备份记录的checkpoint scn来比较,备份自上次
备份以来,数据块头SCN变化过的块,9I版本的这个功能并不能有效减小备份时间,因为他还是要把整个文件读入缓冲区,逐个数据块进行检查和校验,只不过推入输出缓冲区的数据块会少很多,备份片会小很多,如果到备份设备的IO不存在瓶颈,花的时间可能和一次全备差不多,但是从10G版本开始,引入了BLOCK CHANGE TRACKING特性,这次算是真正的增量了。

当这个特性开启后,ORACLE会创建一个trace文件,并起用后台进程CTWR记录变化的数据块,当需要增量备份的时候,就直接读这个文件获得要备份的数据块,速度确实是有质的飞跃

–全备数据库
run
{
    allocate channel c1 device type disk format ‘/opt/oracle/rman/mydb_full_bck%u’;
    backup incremental level 0 database ;
}

allocated channel: c1
channel c1: sid=841 device type=disk

starting backup at 2008-03-01 18:19:10
finished backup at 2008-03-01 18:19:45
全备耗时35

–增量数据
sys@mydb>create table mytable tablespace myspace as select * from dba_objects where 1 = 2;

table created.

sys@mydb>insert into mytable select * from dba_objects;

12064 rows created.

……

sys@mydb>commit;

commit complete.

sys@mydb>

–增量备份
run
{
    allocate channel c1 device type disk format ‘/opt/oracle/rman/mydb_inc_bck%u’;
    backup incremental level 1 database ;
}

allocated channel: c1
channel c1: sid=841 device type=disk

starting backup at 2008-03-01 18:23:34
finished backup at 2008-03-01 18:25:29
老式增量备份耗时1分55秒

–启用BLOCK CHANGE TRACKING特性
sys@mydb> alter database enable block change tracking using file ‘/opt/oracle/oradata/mydb/my_btrace.dbf’ reuse;

database altered.

sys@mydb>startup force;
oracle instance started.

total system global area  786776064 bytes
fixed size                  1302736 bytes
variable size             276827952 bytes
database buffers          503316480 bytes
redo buffers                5328896 bytes
database mounted.
database opened.

–继续增量数据
sys@mydb>drop table mytable;

table dropped.

sys@mydb>create table mytable tablespace myspace as select * from dba_objects where 1 = 2;

table created.

sys@mydb>insert into mytable select * from dba_objects;

12064 rows created.

…..

sys@mydb>commit;

commit complete.

–增量备份
run
{
    allocate channel c1 device type disk format ‘/opt/oracle/rman/mydb_inc_bck%u’;
    backup incremental level 1 database ;
}

allocated channel: c1
channel c1: sid=848 device type=disk

starting backup at 2008-03-01 18:40:52
finished backup at 2008-03-01 18:41:04
使用block跟踪文件后增量备份耗时12秒,时间明显缩短

–通过v$backup_datafile视图观察文件备份时数据块的读取情况
select file#, incremental_level, completion_time, datafile_blocks ,blocks_read,
trunc((blocks_read / datafile_blocks) * 100,2) as “read%”,
used_change_tracking
from v$backup_datafile
where incremental_level > 0
order by completion_time;
     file# incremental_level completion_time     datafile_blocks blocks_read      read% use
———- —————– ——————- ————— ———– ———- —
         1                 1 2008-03-01 18:25:13          131072      131072        100 no
         2                 1 2008-03-01 18:25:13          131072      131072        100 no
         3                 1 2008-03-01 18:25:13          131072      131072        100 no
         4                 1 2008-03-01 18:25:13          131072      131072        100 no
         1                 1 2008-03-01 18:40:57          131072         139         .1 yes
         3                 1 2008-03-01 18:40:57          131072         183        .13 yes
         2                 1 2008-03-01 18:40:57          131072          77        .05 yes
         4                 1 2008-03-01 18:40:57          131072           1          0 yes
关于trace文件:
         在起用BLOCK CHANGE TRACKING时可以指定这个文件的位置,一旦生成,这个文件的就比较重要了,可以看成是数据库的一部分,文件的大小主要是由数据库本身的大小,日志线程数量决定的,他是个二进制文件,创建的时候就包含了数据库所有block的位图映射关系,最小是10M,以后空间以10M为单位增加,每增加一个数据文件,都会导致这个文件内部320K的空间消耗,所以可能一个非常大的数据库,文件数量比较小,他的trace文件要比那些有很多数据文件的小数据库要小很多,由于总是预先分配了所有数据块的位图关系,数据库的频繁更新对trace文件大小并没有影响,metalink Note:306112.1有关于这个文件的说明
         这几天正在考虑数据仓库的备份能否使用这个方法,因为每天有大批量的数据装载,如果全部记录日志传送standby,应用恢复时间会非常久,日志量也是惊人的,另外很多程序员都倾向于使用append+nologging,这样standby的可用性也会大打折扣
         ORACLE 10G支持copy image的增量备份,相当于直接copy了数据文件,然后在文件上应用增量数据块,这种数据同步的方式就不用担心nologging操作,但操作起来比较手工,并且change比较猛的情况下究竟会不会快过日志应用还难说,测试的结果并没有想象中的快,而且还存在bug

10人发表了评论  ↓发表评论↓
  • 不错的,下一步考试将我们数据仓库的备份改成这样子来实现

    blue_prince @ March 1, 2008 |

  • 晕,考虑弄成考试了

    blue_prince @ March 1, 2008 |

  • 你们那边也有这个想法????具体的我还没有测试过,呵呵!!!

    八神 @ March 2, 2008 |

  • 时间是快了,不知道备份出来的文件大小变化大么??

    vogts @ March 2, 2008 |

  • 作成备份集的话会小很多,基本就是变化的数据块

    八神 @ March 3, 2008 |

  • 请问启用BLOCK CHANGE TRACKING特性会对性能有负面影响吗?速度我也测试过,增量是快了很多,但不知道用到生产上,会对其他操作有影响吗(这方面有资料或测试吗?)

    vrv15 @ March 25, 2008 |

  • 性能影响肯定是有的,但我还没作过具体测试,这里要注意的是他的trace file是一个大的位图,建立好了就已经包含了整个DB的块的对应关系,数据块的变更只是更新了trace文件里面对应的标志位,所以这个影响应该是比较小的,按照oracle的说法,每次做增量后,trace文件的标志位会被清除,这个清除的过程应该还是有讲究的,因为也许进行的时候数据块又正在被修改,两个动作应该有个锁定等待,当然这个是备份发生的,你可以选择在不忙的时候做增量备

    八神 @ March 26, 2008 |

  • 恩,多谢了。
    我们这备份到都是晚上进行,主要是担心是否会对其它操作有影响,特别是晚上备份之后的批处理(大量数据装载和修改),不知道是否会影响速度。这个看来还得再测试测试。
    刚看了oracle文档,是有这么一段说会有小的性能影响:”Change tracking is disabled by default, because it does introduce some minimal performance overhead on your database during normal operations …(略)…”
    还有个问题问下,是说在启用BLOCK CHANGE TRACKING后,只有当完成第一次level 0 incremental backup,之后的incremental backup才会受益吗?(看文档一段是这么说的,不知道理解对不对,哈)

    vrv15 @ March 26, 2008 |

  • 是的,增量必须是在level 0的基础上进行的,level 0必须扫描整个数据文件做备份

    八神 @ March 27, 2008 |

  • >﹏<b( ̄▽ ̄)d

    环形变压器 @ December 21, 2009 |

表情:<( ̄︶ ̄)> | (⊙ˍ⊙) | >﹏< | b( ̄▽ ̄)d | (─.─||) | (^_-)

[ Ctrl+Enter提交 ]

DBA