TSM备份DB2：使用 DB2 增量备份

简介

DB2 9.5 提供许多用于数据库可用性和恢复的功能，包括：

• 按需日志归档

• 从分隔映像备份

• 双份日志

• 在 Solaris 上的 Veritas 集群支持

本文讨论对数据仓库的最大备份改进之一 —— 增量备份。增量备份意味着仅对更改进行备份。这个功能允许您在某些数据库环境中更加灵活地设计备份策略。

为什么仅备份更改？

您有没有经历过对保存在文字处理器中的文档进行少量更改，然后重新保存整个文档？您这样做的原因是什么？这很可能是因为您想要确保最后的更改被保存。使用关系数据库时，有些东西比用于管理数据的硬件和软件更加有价值，它就是数据，数据本身是最有价值的资产。只有保护好数据，才能产生其他价值。

DB2 有一些 DB2 引擎可以直接使用的备份和恢复命令。只要数据库发生了变化，备份可以是离线（没有用户连接到数据库）或在线进行的。一般 DB2 备份都是有 DBA 调度的，让它们在特定的时间间隔运行，比如每周、每晚或每小时。“我更改了很多东西，所以我要保存我的工作” 的概念不适用于 DB2（用户正在提交数据除外，不过这也不会复制出一个独立的副本）。相反，每个备份映像之间的更改被 DB2 日志捕获。这两个部分（备份映像和反映备份之后的所有更改的日志）是 DB2 灾难恢复计划的基础构建块。将备份映像和日志保存到处理 DB2 事务的机器之外的其他地方，这样，即使运行 DB2 的机器进水或发生其他故障，您仍然可以恢复数据。

日志

备份映像和日志的概念是为包含许多事务的传统数据库模型设计的，比如仓库中的库存系统。不过，在关系数据库接管了 Information Technology 领域的时候，DB2 仍然用于储存频繁更改的数据。汽车部件仓库的数据库是非常活跃的（汽车比软件更容易崩溃），但财产税数据库中的大部分行的更改则不是很频繁，因为住户入住一所房屋之后，一般都要呆上好几年。在纸张或缩微胶片上的数据难以估量，但大部分都需要我们保存，它们在关系数据库中是非常有价值的。但是，如果为了保存每 n 个星期更改一次的内容而备份美国国会图书馆，则抵消了使用数字储存的好处。

在多媒体应用程序中，大部分数据都储存为大对象（LOB），这些 LOB 数据一般不需要进行日志记录。对于这些情况，即使使用备份-日志策略也不够理想。为此，DB2 引入了增量备份 —— 它仅保存最后的备份之后的更改。

回页首

增量备份的优点

您可以通过两种方式来使用 DB2 跟踪更改，并将更改储存到其他地方以备日后恢复使用：

• 让 DB2 将每个 INSERT
  、UPDATE
  、DELETE
  、CREATE
  、ALTER
  、DROP
  、GRANT
   和 REVOKE
   语句写到日志中。当需要执行恢复时，可以进入最后的数据库备份，然后让 DB2 运行日志并重新创建所有更改（类似于福尔摩斯通过跟踪每个可疑者的踪迹来重构犯罪事实）。这种方法在发生大量事务的环境中非常有效。

• 第二种方法是让 DB2 在每个页被更改时保存该页的一个副本。这就是增量备份的工作原理。

如果数据库非常活跃，那么在每个页发生更改时保存它的副本没有任何意义。因此这最终会在数据库中保留每个页的副本（几乎是一个新的备份映像），这就背离了仅跟踪渐进的页更改的目标。对于这种情况，记录 SQL 的日志可能更快。

另一方面，如果所有更改都集中在少量页上，或者大部分页几乎不发生变化，那么在增量备份映像中储存更改的页能够节省时间和储存空间。如果一个页面未发生任何更改，增量备份就会跳过它。

增量备份在事务比较少的数据库上非常高效，因为您仅保存最后备份之后发生的更改，而不是数据库中的所有页。这使得备份和恢复操作更快、备份映像的体积更小。

回页首

启用增量备份

要指定是否对数据库启用增量备份，需要使用 TRACKMOD
 配置参数。这个参数指定数据库管理器是否跟踪数据库修改，以让备份工具能够检测到应该对数据库的哪些部分进行增量备份，并将其包含到备份映像中。

TRACKMOD
 配置参数可以使用以下值之一：

• NO
  — 禁用增量备份。不跟踪或记录数据库页更新。这是默认值。

• YES
  — 启用增量备份。当启用了更新跟踪之后，首次成功连接到数据库之后更改将变得有效。注意，在增量备份对特定表空间执行备份之前，必须对该表空间进行一个完整的备份（下面的例子提供详细 解析）。

下面的例子显示了如何为 SAMPLE 启用增量备份：

    DB2 UPDATE DATABASE CONFIGURATION FOR SAMPLE USING TRACKMOD YES

在将 TRACKMOD
 设置为 YES
 之后，您必须在允许应用程序更改数据之前备份数据库。换句话说，您必须对数据库进行完整的备份，从而为执行增量备份提供一个基准点。此外，如果您随后在数据库中创建了一个新的表空间，那么必须进行包含该表空间的备份。这可以是数据库备份或表空间备份。在备份之后，增量备份就可以包含新的表空间。

回页首

备份数据的类型

有两种类型的增量备份：

• 完整增量备份：最后一次完整备份（不管该备份是完整的还是表空间备份映像）之后更改的所有页的映像。例如，以下命令对 SAMPLE 数据库执行完整的增量备份：

      DB2 BACKUP DB SAMPLE ONLINE INCREMENTAL USE TSM

• 增量（Delta）。最后一次备份（增量、渐进或完整的备份映像）之后更改的所有页。例如，以下命令对 SAMPLE 数据库执行增量备份：

      DB2 BACKUP DB SAMPLE ONLINE INCREMENTAL DELTA USE TSM

这为恢复受损数据库提供 4 种类型的备份数据：

• 完整的备份映像。这是任何恢复策略的构建块，如果没有完整的备份映像，就不能开始恢复过程。如果让备份上线，则需要在备份发生时发出的所有事务的日志。要恢复完整的备份，重播备份之后的所有事务的日志，该过程结束之后恢复就完成了。

• 增量备份。这包含最后完整备份之后的所有更改。要恢复增量备份，重播增量备份之后的所有事务的日志，该过程结束之后恢复就完成了。

• 增量备份。这包含最后一次任何类型的备份之后的所有更改。如果最后的备份是一个完整的备份映像，那么它和增量备份将提供最完整的备份。如果在增量备份之前执行了增量备份，则需要增量备份、增量备份以及增量备份所依赖的完整备份映像。如果一个增量备份之前执行了一个或多个其他增量备份，那么您需要在执行增量备份或完整备份映像之后执行的所有增量备份。

• 日志。日志包含可以恢复的最后一次备份之后的所有事务。

还可以从另一个角度考察备份 —— DB2 支持在整个数据库级别和特定表空间级别的备份（更加细粒度的备份和恢复允许您将备份和恢复限制到关键的表空间）。备份和恢复增量和渐进映像同样适用于表空间。

回页首

恢复策略

让我们先看这样一个针对数据库的恢复策略，该策略将在每个星期日执行一次完整备份，而在每天晚上执行一次增量备份，如 图 1 所示（图中没有显示日志，但在最后的恢复之后需要使用）。

• 如果您需要恢复到 Monday，则需要使用 Sunday 夜间备份映像进行恢复，并应用所有可用的日志。

• 如果您需要恢复 Tuesday 和 Sunday 之间的数据，则需要恢复前一个 Sunday 的完整备份映像，然后恢复前一个夜间的增量备份映像，最后应用恢复的渐进映像之后的所有日志。

所有恢复都需要：

• 一个完整的备份映像

• 0 个或 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 历史文件。如果您所在的公司可能丢失灾难恢复所需的归档日志，那么使用渐进和增量映像将给您提供多一份保障。

所以不管在什么情况下，都应该花时间建立一个备份和恢复策略。下面提供一些注意事项：

• 在进行基础性更改之前执行完整备份，比如迁移、安装修复包或大的应用程序修改。

• 使用 DB2 db2ckbkp
   命令检查备份映像的完整性。DB2 Command Reference 详细介绍了这个命令（在 参考资料 部分提供相关链接）。

• 使用 DB2 db2ckrst
   命令查询历史文件，并确保您对增量备份的需求与 DB2 的记录相符合。

• 尝试执行一次恢复，了解所需的时间以及从哪里找到所有相关的部分，比如备份映像和日志。需要有多个人了解恢复过程（毕竟您以后可能休假或退休）。

• 如果您计划使用前滚时间点恢复或将表空间恢复到特定时间点，一定要理解数据库模式。如果特定的表空间包含的表与其他的表空间中的表存在引用限制，那么首先恢复它不会改进可用性。

• 如果使用在线备份，要知道除非具有在 DB2 备份数据库时发生的所有事务的日志，否则备份映像没有任何作用。

• 制定一个计划，如果备份不能完成应该怎么做：

• 您将在允许生产继续之前完成备份吗？

• 您有足够的日志来回溯到上一个备份映像吗？

• 如果用户在备份完成之前要求访问数据库，您能调整备份策略吗？

如果 DBA 不了解您定义的备份策略和规则，那么在出现灾难时他们会让事情变得更糟。如果他们了解这些规则，他们就能够确保正确有序的执行备份恢复。