转自:http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0910db2incrementalbackup/index.html
简介
DB2 9.5 提供许多用于数据库可用性和恢复的功能,包括:
本文讨论对数据仓库的最大备份改进之一 —— 增量备份。增量备份意味着仅对更改进行备份。这个功能允许您在某些数据库环境中更加灵活地设计备份策略。
为什么仅备份更改?
您有没有经历过对保存在文字处理器中的文档进行少量更改,然后重新保存整个文档?您这样做的原因是什么?这很可能是因为您想要确保最后的更改被保存。使用关系数据库时,有些东西比用于管理数据的硬件和软件更加有价值,它就是数据,数据本身是最有价值的资产。只有保护好数据,才能产生其他价值。
DB2 有一些 DB2 引擎可以直接使用的备份和恢复命令。只要数据库发生了变化,备份可以是离线(没有用户连接到数据库)或在线进行的。一般 DB2 备份都是有 DBA 调度的,让它们在特定的时间间隔运行,比如每周、每晚或每小时。“我更改了很多东西,所以我要保存我的工作” 的概念不适用于 DB2(用户正在提交数据除外,不过这也不会复制出一个独立的副本)。相反,每个备份映像之间的更改被 DB2 日志捕获。这两个部分(备份映像和反映备份之后的所有更改的日志)是 DB2 灾难恢复计划的基础构建块。将备份映像和日志保存到处理 DB2 事务的机器之外的其他地方,这样,即使运行 DB2 的机器进水或发生其他故障,您仍然可以恢复数据。
日志
备份映像和日志的概念是为包含许多事务的传统数据库模型设计的,比如仓库中的库存系统。不过,在关系数据库接管了 Information Technology 领域的时候,DB2 仍然用于储存频繁更改的数据。汽车部件仓库的数据库是非常活跃的(汽车比软件更容易崩溃),但财产税数据库中的大部分行的更改则不是很频繁,因为住户入住一所房屋之后,一般都要呆上好几年。在纸张或缩微胶片上的数据难以估量,但大部分都需要我们保存,它们在关系数据库中是非常有价值的。但是,如果为了保存每 n 个星期更改一次的内容而备份美国国会图书馆,则抵消了使用数字储存的好处。
在多媒体应用程序中,大部分数据都储存为大对象(LOB),这些 LOB 数据一般不需要进行日志记录。对于这些情况,即使使用备份-日志策略也不够理想。为此,DB2 引入了增量备份 —— 它仅保存最后的备份之后的更改。
增量备份的优点
您可以通过两种方式来使用 DB2 跟踪更改,并将更改储存到其他地方以备日后恢复使用:
如果数据库非常活跃,那么在每个页发生更改时保存它的副本没有任何意义。因此这最终会在数据库中保留每个页的副本(几乎是一个新的备份映像),这就背离了仅跟踪渐进的页更改的目标。对于这种情况,记录 SQL 的日志可能更快。
另一方面,如果所有更改都集中在少量页上,或者大部分页几乎不发生变化,那么在增量备份映像中储存更改的页能够节省时间和储存空间。如果一个页面未发生任何更改,增量备份就会跳过它。
增量备份在事务比较少的数据库上非常高效,因为您仅保存最后备份之后发生的更改,而不是数据库中的所有页。这使得备份和恢复操作更快、备份映像的体积更小。
启用增量备份
要指定是否对数据库启用增量备份,需要使用 TRACKMOD 配置参数。这个参数指定数据库管理器是否跟踪数据库修改,以让备份工具能够检测到应该对数据库的哪些部分进行增量备份,并将其包含到备份映像中。
TRACKMOD 配置参数可以使用以下值之一:
下面的例子显示了如何为 SAMPLE 启用增量备份:
DB2 UPDATE DATABASE CONFIGURATION FOR SAMPLE USING TRACKMOD YES |
在将 TRACKMOD 设置为 YES 之后,您必须在允许应用程序更改数据之前备份数据库。换句话说,您必须对数据库进行完整的备份,从而为执行增量备份提供一个基准点。此外,如果您随后在数据库中创建了一个新的表空间,那么必须进行包含该表空间的备份。这可以是数据库备份或表空间备份。在备份之后,增量备份就可以包含新的表空间。
备份数据的类型
有两种类型的增量备份:
DB2 BACKUP DB SAMPLE ONLINE INCREMENTAL USE TSM |
DB2 BACKUP DB SAMPLE ONLINE INCREMENTAL DELTA USE TSM |
这为恢复受损数据库提供 4 种类型的备份数据:
还可以从另一个角度考察备份 —— DB2 支持在整个数据库级别和特定表空间级别的备份(更加细粒度的备份和恢复允许您将备份和恢复限制到关键的表空间)。备份和恢复增量和渐进映像同样适用于表空间。复策略
让我们先看这样一个针对数据库的恢复策略,该策略将在每个星期日执行一次完整备份,而在每天晚上执行一次增量备份,如 图 1 所示(图中没有显示日志,但在最后的恢复之后需要使用)。
所有恢复都需要:
注意,在这些场景中,每个增量备份都会不断增长,直到构成一个完整的备份。这是因为随着时间的推移,增量备份包含越来越多的更改页。例如,Saturday 备份可能包含 6 天的更改,而 Monday 备份仅包含一天的更改。
图 1. 完整和增量备份映像
如 图 2 所示,如果每晚只执行一个增量备份,则备份更小。
图 2. 完整的增量备份映像
通过使用增量备份,从 Monday 到 Saturday 的夜间备份需要的存储空间更少,完成的速度也更快。记住,如果使用夜间增量备份,那么执行恢复时需要使用在最后一次完整或增量备份之后的所有增量备份。这与 图 1 所示的策略不同,它仅需要一个完整的备份、一个增量备份和日志。
为了帮助您跟踪备份,DB2 提供对数据库的备份历史进行跟踪的历史文件。您可以使用 LIST HISTORY 命令查询数据库备份历史。DB2 Command Reference(在 参考资料 部分提供相关的链接)包含 LIST HISTORY 命令语法的完整描述。例如,以下命令列出 SAMPLE 数据库的所有备份和恢复操作:
DB2 LIST HISTORY BACKUP ALL FOR SAMPLE |
DB2 本身使用历史文件来确定执行恢复时是否需要使用以前的映像,并尝试自动恢复它们。这将导致如 图 2 所示的备份映像链。
图 3 显示了恢复如何使用完整的备份映像、最后的增量备份、上一次增量备份之后的所有增量备份和日志。在这个例子中,如果在 Thursday 执行了增量备份之后,则不再需要从 Monday 到 Wednesday 的增量映像。注意,如果其中一个增量或渐进映像受损之后,只要您还有完整的备份映像和所有日志,仍然可以以不需要增量或增量备份的恢复的方式执行恢复。在这个例子中,Saturday 增量映像受损,因此您只需恢复到 Friday 增量映像,然后使用日志从该点开始恢复。
图 3. 完整、渐进和增量备份映像
因为 DB2 使用历史文件来计算增量备份的下一个步骤,所以要从历史文件删除条目时一定要慎重(使用 PRUNE HISTORY 命令)。历史文件是一段元数据,它对增量备份的重要性与系统目录对数据库的重要性相当。
自动恢复
如果您使用 INCREMENTAL AUTOMATIC 关键字进行恢复,那么 DB2 将决定恢复什么内容。例如:
DB2 RESTORE DATABASE SAMPLE INCREMENTAL AUTOMATIC TAKEN AT (SAT) |
当您指定 INCREMENTAL AUTOMATIC 时,DB2 决定是否需要以前的备份映像并尝试自动恢复它们。历史文件决定所需的备份映像的顺序。DB2 从最后一个包含需要恢复的所有表空间的完整副本的备份映像开始,然后应用随后的渐进映射。随后的备份映射不需要包含正在恢复的所有表空间。
在开始恢复之前,您还可以使用 db2ckrst 实用程序解析历史文件并获取所需的备份映像的描述。
![]() ![]() |
![]()
|
结束语
增量备份能够为以只读为主、偶尔执行 INSERT、UPDATE 或 DELETE 活动的数据库提供很好的保护。此外,它也非常适合用于更改局限在一小部分表空间中的数据库。
因为增量备份策略在备份时依赖 4 中数据类型(完整映像、渐进映像、增量映像和日志),所以您要根据自己的需求使用它们。此外,还要确保所有维护数据库的 DBA 理解该策略并了解如何读取 DB2 历史文件。如果您所在的公司可能丢失灾难恢复所需的归档日志,那么使用渐进和增量映像将给您提供多一份保障。
所以不管在什么情况下,都应该花时间建立一个备份和恢复策略。下面提供一些注意事项:
如果 DBA 不了解您定义的备份策略和规则,那么在出现灾难时他们会让事情变得更糟。如果他们了解这些规则,他们就能够确保正确有序的执行备份恢复。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/15082138/viewspace-623285/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/15082138/viewspace-623285/