DB2 基础: IBM DB2 Universal Database for Linux, UNIX and Windows 备份实用程序

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

Dale McInnis (dmcinnis@ca.ibm.com), DB2 开发人员, IBM Canada Ltd.
Paul C Zikopoulos (paulz_ibm@msn.com), DB2 优势技术团队成员, IBM Canada Ltd.

2005 年 1 月 01 日

理解 DB2 UDB 备份实用程序最近的、最新的特性。本文包括备份进程模型、关于各种在线和离线备份的细节、关于使用 Tivoli Storage Manager 进行备份的提示和技巧、关于自我调优功能的信息，以及精心策划备份策略的理由。

简介

我们花了大量时间同客户和用户组谈关于 DB2 Universal Database for Linux、UNIX® 和 Windows® (DB2) 中最新、最重要特性的承诺。但事实总是：当我们在讲一个话题时，如果问听众他们是否熟悉一项新的关键特性，即使这项特性已经存在有一段时间了，大多数人还是没有听说过这项特性。在本文中，我们将带您经历一次 BACKUP 实用程序之旅，并展示该实用程序在 DB2 中的工作原理。我们将谈到它的内部组成，以及已经增加了有一段时间的一些新特性，这些新特性使它的速度更快，功能更丰富。

回页首

为什么要备份？

对于为什么应该定时进行备份（并测试这些备份的可恢复性），有很多的原因。备份中的数据对您虽然没什么用，但它却是您企业的救命稻草，所以把备份数据当作您的工作吧。

以下情况都需要备份：为了在出现应用程序错误时进行恢复，为了复制数据库（例如，填充开发或测试系统），为了将数据库转移到新的硬件上，为了迁移到一个新的级别，为了确保软件更新保护前后的可恢复性，为了建立某种灾难恢复（DR）或高可用性（HA）拓扑结构，等等。

有趣的是，如今人们做备份的最大原因是确保能够在出现应用程序错误时进行恢复。可以说，如今的硬件（H/W）已经相当安全了。例如，双电源、RAID、双控制器等等都非常接近标准，如果一切设置无误的话（显然有例外），遭受 H/W 停机事故的几率很小。但如何才能避免人为的错误呢？

回页首

为什么是 DB2 备份而不是文件系统备份？

很多新的数据库管理员（DBA）都会问这个问题。主要原因是，DB2 在努力保持热缓存（实际上是在内存中应用程序所需的数据）方面非常主动。随着 64-位模型的壮大，这会成为一种趋势，并且这种趋势不会减缓（也不应该减缓，因为能够放在处理器的 L1、L2 或 L3 缓存或随机存储器中的数据越多，工作负载就运行得越快。实际上，您需要积极主动的数据缓存，因为它使数据尽可能远离磁盘，从而避免高代价的 I/O 周期。

当 DB2 在运行的时候，如果要拷贝一个文件系统上的文件，那么肯定会导致数据的不一致，DB2 不能保证可以恢复数据。例如，如果数据库在运行，那么执行文件系统复制操作时将得不到即时点（point in time,PIT）上数据库的快照。您应该坚持使用 DB2 备份来确保数据的一致性 —— 否则，如果不终止整个 DB2 实例的话，就无法确保数据的一致性。

而且，有了基于 DB2 的备份，就可以利用 DB2 的在线能力，它允许在备份过程中执行 DDL 和 DML，这样业务操作就可以像往常一样继续。由于可以在表空间级进行备份，所以还可以进行粒度控制。这样可以将那些关键的表分离出来进行备份，而留下其他那些不需要备份或者不需要经常备份的表。

DB2 备份还有助于可恢复性。您可以通过日志前滚到所选择的某个 PIT 上。换句话说，您可以细粒度地控制系统在“起死回生”时的样子，而不是像使用文件系统的方法那样只是得到一个静态的快照（这种快照很可能是不一致的）。

DB2 还支持“子集（subset）”恢复。例如，如果备份 5 个表空间，那么可以选择只恢复其介质出现故障的那个表空间。而在文件系统备份中，要么是全部恢复，要么一个也不恢复。

回页首

关于 DB2 备份

DB2 备份实用程序通常被集成在 DB2 引擎中，它不是一个附带的实用程序。我们曾经提到，DB2 备份实用程序具有粒度控制能力。备份镜像（backup image）可以是以下任何组合：

• 数据库或一系列的表空间。
• 离线或在线。
• 完全（full）、增量（incremental）或差异（delta）。

DB2 中的备份实用程序对数据页进行物理上的复制。这种备份不是文件系统的备份，而是逻辑上的备份。DB2 备份镜像包括数据以外的附加信息，例如元数据、数据库配置、历史文件、表空间定义，等等。

当备份一个系统时，DB2 将数据从磁盘读入到它的输入/输出（I/O）缓冲区，并将这些数据从缓冲区写到目标设备或第三方存储管理软件（例如 IBM Tivoli Storage Manager）。从 DB2 V8.2 开始，对于在线备份，日志文件是备份镜像的一部分（显然，离线备份不需要日志文件就可以进行恢复）。值得注意的是，临时表空间和空闲 DMS 盘区（extent）不是备份镜像的一部分。DB2 备份实用程序还具有压缩功能（从 DB2 V8.1.4 开始）和 throttling 功能（从 DB2 V8.2 开始）。我们将在本文的后面讨论这些功能。

DB2 有一个非常高效的备份实用程序，它可以将从数据库读出的数据页分成多个部分，并以随机的顺序将它们写到目标设备。换句话说，数据页完全不是按照它们在存档介质上的表关联顺序存放的。DB2 这样做是为了优化备份实用程序的性能（我们假设备份要多于恢复）。DB2 备份实用程序还支持原始设备。

DB2 中提供了三种不同的备份方式：

• 完全备份使您得到完整的备份（有时候也称 0 级备份）。
• 增量备份捕捉自上一次完全备份以来的所有变化（有时候也称 1 级备份）。
• 最后，差异备份捕捉自上一次任何类型的备份以来的一切变化（有时也称 2 级备份）。

备份进程模型

这里有必要讨论一下 DB2 备份进程模型。如果知道 DB2 生成的进程在做些什么，则有助于理解系统的性能。 图 1 解释了 DB2 中的备份进程。

从左边可以看到 DB2 表空间和它们相关的容器。当调用备份实用程序时，DB2 将生成 db2agent 进程，以便控制缓冲区操纵者（ db2bm 进程用于将数据从磁盘读到共享内存）与 db2med 进程（从共享内存读数据并将数据页写出到目标设备）之间的流。

这些进程的运行速度没有限制，但是，您可以根据自身环境的工作负载通过 DB2 的 throttling 功能控制它们的速度。为了为这个实用程序设计尽可能快的架构，在对缓冲区操纵者编写代码时，已经使它不必将数据发给特定的控制器。这就像是一场“赛跑” —— DB2 不关心数据页在备份介质上的存放顺序，只关心数据页到达备份介质的速度有多快。

然而数据页之间还是有一定的关联：每个表空间将被指定给一个单独负责处理该表空间中所有数据的进程。缓冲区操纵者的数量由调用备份实用程序时的 parallelism 选项控制。例如，如果将此选项设置为 2，那么将会有两个 db2bm 进程，每个进程并行地读取两个不同的表空间。

如果要备份数据到一个文件系统，并且这个文件系统是多个磁盘的一个虚拟系统，那么应该多次指定挂载点（mount point）。例如，在 Windows 环境下的 DB2 中，您将输入以下命令：

backup database sample to c: c: c:

在这个例子中，DB2 将生成 3 个到存档介质的 db2med 进程，然后并行地将数据页从 db2bm 进程写到这三个进程。

增量备份

增量备份首先在 V7.2 版中找到立身之处。由于它是被首先引入的，我们已见证了这种类型的备份受欢迎程度的日益增加 —— 尤其是在只有很小一部分数据会变化的数据仓库中。

增量备份允许只备份自上一次备份以来发生变化的索引和数据页。不过有一个例外，对于“脏（dirty）”表空间中的 long 型字段和大型对象数据，总是需要进行备份。对于这一类的数据没有增量支持，因为这些数据类型具有不同于索引和数据页的物理格式，目前 DB2 在备份时不确定这样的数据是否有变化。在以后版本的 DB2 中这个例外就不复存在。

图 2 展示了 DB2 中提供的不同类型的部分备份方式：

从这个图中可以看到，增量备份实际上是以上一次的完全备份为基础。由于完全备份是在星期天进行的（在我们的例子中是如此），这意味着在星期二进行的增量备份将包括星期一和星期二的所有变化。

差异备份以上一次的增量备份或差异备份为基础。对于差异备份，需要维护自上次完全备份以来采取的所有备份，以便能够重构数据。例如，为了将数据恢复到星期三工作结束时，需要星期一、星期二和星期三的差异备份镜像（或星期三的日志文件）。如果在星期二做了增量备份，那么只需要星期二的增量备份镜像以及星期三的差异备份镜像（或日志文件）即可。

除了发生变化的数据页之外，增量备份还包括数据库的元数据（数据库配置、历史文件、表空间定义等），以便在恢复时起到辅助作用。元数据不是增量复制的，而是每次都一一完全复制。

默认情况下，DB2 数据库没有被配置为支持增量备份，因为为了使 DB2 能执行这类备份，会对运行时性能产生一个非常小的影响。要启用这种备份，可以将 TRACKMOD 数据库配置参数设置为 ON （对这个参数的更改要到下一次数据库活动时才生效）。

如果启用了 TRACKMOD，则第一个写操作将把数据的主机表空间标记为“脏（dirty）”。如果这个表空间不是脏的，那么在备份开始的时候，DB2 完全不会理会它。如果看到一个表空间中有一个脏位（dirty bit），它将继续检查作了标记的表空间中的盘区（这些表空间也用脏位作了标记），最终 DB2 只将发生了变化的数据页放入到备份镜像中。用于支持增量备份的跟踪特性完全是内部的，不需要考虑任何存储方面的因素。

在采取非增量备份之前，增量备份是不允许的，非增量备份为增量备份奠定了基础，以便后者可以恢复 —— 这是为了支持总需要非增量基础镜像的增量存储。

在线备份

DB2 可以执行在线备份或离线备份。在对数据库进行常规的 SELECT、INSERT、DELETE 和 UPDATE 活动的同时可以执行在线备份。在 DB2 中运行在线备份的惟一约束是：当一个表空间正在被备份的时候，不能删除这个表空间。

对于离线备份，DB2 知道应用程序只是从数据库中读取数据，因此无需担心锁的问题。而对于在线备份，事情就有所不同。DB2 必须为在线备份实现一个锁策略。对于大型对象和 long 字段数据，DB2 将 Intent None (IN) 锁升级为 Share (S) 锁，因而要慢大约 10%。

在线备份很可能需要从 UTIL_HEAP 内存分配中得到更多的内存，以便为一些帮助支持这种操作的内部结构分配内存。

回页首

数据库历史文件

数据库历史文件正成为数据库引擎中越来越关键的部分。数据库历史文件是对管理操作的一种记录。任何类型的备份镜像都在各自存储数据库历史文件（它是我们前面详细提到的元数据的一部分）。在历史文件中的事件记录包括诸如备份、恢复、日志前滚、装载、数据库或表空间的 queiscing、表空间的修改以及被删除的表（当被删除的表的恢复被支持时）。与记录的操作有关的信息包括：受影响的对象（数据库、表空间或表）、位置和设备类型（备份镜像或装载复制）、相关日志文件的范围、操作的起始和完成时间，以及产生的 SQLCA 代码等。以前，数据库历史文件是一种信息文件，您可以对其进行查询。现在 DB2 使用该文件来支持可恢复性，例如自动恢复。新的日志管理器也使用这种文件。

这种信息被放在一个文件中，而不是放在 DB2 表中，因为需要这种信息来执行恢复操作。如果数据库不可用，那么就不能利用它来进行数据库恢复。因此，数据库历史数据存储在一个 ASCII 文件中，并放在备份镜像中，我们可以从中检索和处理它。

回页首

第三方备份供应商支持

备份期间 DB2 用于写出数据的介质进程（media process）是构建在一套公布的接口之上的，从 1993 年开始这些接口就已经向开发市场提供。这导致对当今大多数主流备份供应商的广泛 DB2 支持，包括 IBM Tivoli Storage Manager (TSM)、Veritas NetBackup、Legato NetWorker、Compuer Associates 等等。

任何供应商可以使用这些接口来将他们的存档解决方案集成到 DB2 中，如 图 3 所示：

在将备份信息“插入”到供应商的存档软件中时，DB2 不是将备份信息写入到文件中，而是将备份数据写入这些接口，然后以位流的形式直接将它们发送到目标介质进程服务器。

例如，如果使用 TSM，那么 DB2 将装载 TSM API 等。这些库被直接装载到 DB2 内核中，并在我们的地址空间中运行。您无需担心供应商插入式代码（从 DB2 V7+FP11 开始）的质量，因为 DB2 将保护实例地址，使其不受第三方代码失效的影响。实际上，在执行每个操作之前，DB2 都将获取以前的信号处理程序的状态，并在事后重现设置它们。这意味着，即使供应商的代码中断，数据库引擎也不会停机（但很显然，备份操作本身将失败）。

DB2 与 Tivoli Storage Manager 的集成已有很长的历史。实际上，DB2 是第二个曾经支持 TSM API 的应用程序。由于 DB2 与 Tivoli（实际上它是一种 IBM 产品）悠久的集成历史，所以我们直接免费发布对 TSM 的支持。

Tivoli Storage Manager 提示和技巧

通过设置 DB2 来使用 TSM 是件很简单的事。

首先，您需要运行 dsmapipw 实用程序（以具有管理权限的用户身份），以设置 TSM 密码。该实用程序位于 sqllib\adsm 目录中。这个实用程序对用于节点的 TSM 密码进行加密，并将其存储到磁盘上。在使用 TSM 和 DB2 时，人们碰到的 60% 的问题都是由于这一步执行失败而引起的。如果没有正确设置密码，那么将收到一个 137 错误码。

接下来，导出特定于 DB2 TSM 的环境变量。有三个可以设置的环境变量：

• DSMI_DIR 是 TSM 客户机的安装目录。
• DSMI_CONFIG 是设置 TSM 时所在的配置。
• DSMI_LOG 指定记录任何错误的文件。

当启动实例时，所有这些设置都将被捕捉，因此，改变其中任何一个设置（以及第一次设置 DB2，使其使用 TSM 时）都必须重新启动实例。如果更改了任何配置参数，只需重新启动实例即可。例如，如果您更改了 TSM 配置文件中的任何特定的 TSM 设置（例如您想与某台 TSM 服务器通信），则无需重新启动数据库引擎。这些环境变量通常位于 DB2 实例的用户配置文件中。

TSM 以时间戳来惟一地标识所有备份。DB2 在 TSM 服务器上并不使用期限（expiration）策略。这一点很重要，因为它意味着您的备份不会过期，因此需要制定一个计划来处理这种情况。

在 DB2 V7 中，DB2 不会删除备份，而是将它们标记为非活动（inactive），所以需要设置 TSM，以便保留非活动的备份（这不是默认设置）。在 DB2 V8 中，这种情况有所变化。现在，当您想要删除一个备份时，不管 TSM 管理类的定义如何，都可以执行删除操作。

在 DB2 V7 中，如果使用 TSM 在节点上备份一个数据库，那么只有执行该备份的用户才能恢复这个数据库。这在 DB2 V7 环境中会导致一些问题，为了恢复到另一台服务器，您必须“伪装”成原先的节点，并且要知道它们各自的密码。您必须在目标节点上创建一个空的数据库，设置 TSM_NODENAME、TSM_PASSWORD、TSM_OWNER 数据库配置参数，然后在 dsm.opt 文件中更改 PASSWORDACCESS=PROMPT，再将 NODENAME 注释掉。

在 DB2 V 8.2 中，通过附件的“供应商选项”支持，已经消除了这种复杂性。该特性允许将初始参数直接发送到 TSM API，其中包括生成备份镜像时所在节点的名称以及 DB2 实例的初始 ID。您不再需要知道节点 TSM 的初始密码。将一个备份镜像恢复到任何节点需要两步：

1. 在生成备份镜像之后，必须使用 db2adutl 授权选项将访问该镜像的访问权限授给所需的节点。例如：

   db2adutl grant newuser on nodename newhost for db mydb

   
   
2. 在新的目标节点上，必须在备份命令中使用 'options' 字段。例如：

   db2 restore db mydb use tsm options 'fromnode=originalnode fromuser=originalinstance'

   
   

最后，在 DB2 V8 中，随着 db2audtl 实用程序的引入，对于在 TSM 服务器上如何管理 DB2 备份也有所增强。之前，由于 DB2 的命名惯例，对备份的管理总是导致一定程度的复杂性。DB2 为备份文件命名，因而您不能依赖 TSM 管理类来管理它们，因为它们有惟一的名称，并且永远不会过期。

db2audtl 命令有 7 个选项：

• DELETE：用于将备份标记为非活动（低于 DB2 version 8 的版本），删除备份（DB2 version 8）和删除日志。对于低于 DB2 version 8 的版本，TSM 将标记非活动 DB2 数据库备份对象，以便基于相关管理类中的 备份复制组（backup copy group）定义执行删除操作。在运行 TSM Expire Inventory 命令时，将从 TSM 服务器上删除被标记要删除的对象。为了让 db2adutl 能够删除数据库备份，必须为 TSM 将 Backdel 参数设置为 yes。为了清除保存在 TSM 服务器上的 DB2 日志，需要为节点设置 Archdel Yes 参数。这些参数可以在注册 TSM 节点时指定，也可以通过在 TSM 服务器上执行对节点信息的更新来设置。
• QUERY：列出在这个节点上创建的所有或特定的 DB2 对象。可以使用 Show inactive 子句来查看已经被标记为非活动的备份镜像。
• EXTRACT：从 TSM 对象创建磁盘镜像。如果一个数据库镜像标记为非活动，那么它就不能再被恢复，但是仍然可以从 TSM 服务器提取该数据库镜像，而被提取的镜像可用于执行恢复。注意，在 DB2 version 8 中，db2adutl 用于删除一个对象，它不只是将对象标记为非活动，而是将其设为在 TSM 服务器上立即过期。
• VERIFY：从 V6 开始，还有一个 VERIFY 选项随 db2adutl 实用程序发布。它允许从 TSM 服务器读取镜像，并在它上面执行验证。通过 TAM 运行 db2ckbkp 实用程序（以前称为 dumpimage）基本上是验证镜像是否可恢复的一种方法。
• GRANT：为任意主机上的任意用户提供访问 db2 备份镜像和日志文件的能力，这些镜像和日志文件与发出 GRANT 选项的节点上生成的数据库有关。
• REVOKE：为任意主机上的任意用户提供撤销访问权限的能力，这些访问权限是针对与发出 REVOKE 选项的节点上生成的特定或全部数据库相关的 db2 备份镜像和日志文件的。
• QUERYACCESS：为任意主机上的任意用户提供查询被授予的访问权限的能力，这些访问权限是针对与发出 queryaccess 选项的节点上生成的特定或全部数据库相关的 db2 备份镜像和日志文件的。

为了完整起见，下面的代码展示了 DB2 V7 中对 TSM 的支持：

回页首

DB2 V8.1 和后续版本中 BACKUP 中的新特性

在这一节中，我们将讨论 DB2 V8.1 以及其他后续版本中引入的新特性。

DB2 V8.1.2

在 DB2 V8.1.2 中，我们支持通过 throttling 来限制备份实用程序。这是一个非常强大的特性，那些竭尽全力遵从严格的服务水平协议（SLA）的 DBA 们都准备试一试这个特性。

首先让我们来确定问题。在文中我们已提出，设计 DB2 备份实用程序时需要一直牢记一件事：性能。这正是我们的客户要求我们做的。当客户询问性能的时候，他们面临的是日益缩水的批处理窗口，而不得不花越来越多的精力去维护越来越小的维护窗口。于是世界变了。业务环境变成一个 24x7 连续可用的东西，它不会因任何人、任何事而停止。

具有讽刺意味的是，那些要求我们尽可能快地完成备份实用程序的客户，现在又要求我们找到一种办法让它慢下来。因此，又引入了实用程序调节的概念。

实用程序调节使您可以为备份实用程序定义一个策略，以便通过设置一定百分比的“正常操作”，使该实用程序不会影响生产工作负载 —— 换句话说，它将限制 DB2 可以使用的资源。根据业务环境中不同的因素，您可以加快、减慢或暂停这个实用程序。

图 6 展示了说明调整（throttle）一个实用程序（例如备份）的效果的例子。

在前面的图中可以看到没有运行备份时的吞吐量（每分钟事务数）。当 BACKUP 全力运行时，这个系统的事务率会下降到 100 Tpm 以下。调整允许您设置一个非自适应（non-adaptive）的事务率（该数字表明允许对生产工作负载的影响程度），以便根据环境定制 BACKUP 的吞吐量。

如果 SLA 以每分钟只维护 300 多个事务为基础，那么您可能要设置一个 70% 的非自适应调节率（throttle rate，意即 BACKUP 在消耗资源时需保证对生产环境的影响只有 30%）。于是 DB2 将调整 BACKUP 的可用资源，这样，对生产工作负载的平均影响就会是 30%。

DB2 V8.1.4

在 DB2 V8.1.4 中，我们通过一个可选的压缩特性和一些新的 TSM 集成命令（GRANT 和 REVOKE）增强了备份实用程序。

您可以要求 DB2 压缩数据库备份。备份实用程序在到达磁盘之前在缓冲区中压缩数据。数据是通过一个修改后的 Lempel-Zev (LZ) 算法（在 "A Technique for High Performance Data Compression," Welch, Terry A., IEEE Computer, vol. 17, no. 6 (June 1984), pp. 8-19 中有描述）在被从数据库中读出时压缩的。默认的算法是平台无关的，因此可以将来自 AIX 机器上 DB2 的备份放到 HP 机器上的 DB2 上（little endian 编码只能放到 little endian 编码的数据库上，对于 big endian 编码的备份镜像也是如此）。

您可以通过备份实用程序的开放插件特性提供自己的压缩算法。如果您已经指定了自己的压缩库，而丢失了您的机器，那么不用担心！DB2 会将您的算法的可执行文件复制到备份镜像中，因此我们还可以恢复您的镜像。

下面的图展示了一个通过使用 DB2 BACKUP 压缩算法来节省空间的示例。在这个例子中，我们使用压缩选项备份了一个典型的 ERP 数据库。备份的大小大约是从 180MB 变为 30 MB。

在另一场测试中，一个完全随机化的数据库（由 ASCII 字符和数字组成）从 250MB 变为 185MB。

记住，这种压缩是基于软件的，因此它所带来的好处是以系统额外的 CPU 周期为代价的。例如，在 ERP 例子中，备份时间从 56 分钟增加到 1 小时 46 分钟。然而，如果网络的带宽是一个瓶颈的话，压缩会有所帮助，因为随着备份镜像的缩小，通常您可以体验到介质 I/O 时间减少了。

DB2 V8.2.4 还引入了新的 TSM GRANT/REVOKE 命令，在本文前面 TSM 提示和技巧一节 db2adutl 的讨论中，对这个命令进行了描述。

DB2 V8.2

DB2 V8.2 在 BACKUP 领域引入了很多增强。首先，备份实用程序现在是自我调优的（或者至少在调优方面做得更好）。实际上，在大多数情况下，您不必花时间决定为缓冲区的数量指定什么值，决定所需的并行度或者缓冲区的大小。 图 8 中展示了分别运行 DB2 V8.2 和 DB2 V8.1 中 BACKUP 的一些例子。

在 DB2 V8.2 中，备份实用程序对于缓冲区数量、并行度和缓冲区大小有自主的、优化的设置。这些设置是由 DB2 根据表空间数量、每个表空间的 EXTENTSIZE、可用 CPU 数量以及可用内存而精心挑选的。

每次运行 BACKUP 命令时，如果是从一个 API 调用 BACKUP，而在调用该命令时，前面提到的任何参数中有未指定且没有被设为 0 的，那么 DB2 将为您选择自主的设置。

DB2 V8.2 还为 DB2 引入了警告功能，它可以提醒用户需要备份，或者真正地执行备份，或者在警告同时执行备份。这比按一定周期调度数据库备份要更胜一筹。您可以定义触发备份操作的业务级策略。例如，自上次备份以来所消耗的总日志空间可以触发一个自动的备份。那些不希望 DB2 为他们做任何事情的 DBA 仍可以利用这个功能来接受 DB2 的电子邮件通知，当 DB2 根据 DBA 定义的策略断定是时候再执行一次备份时，DBA 就可以收到这样的邮件 —— 当然，DB2 将把该功能与调节结合在了一起，以确保生产环境不受影响。

最后，数据库和表空间的在线备份镜像将包括一组日志文件，在将备份镜像恢复到某个一致的时间点时，这些文件是必需的。这使客户机可以发布一个单独的对象到灾难恢复站点，后者允许客户将数据库恢复到一个一致的时间点。在我们的经验中，很多客户机在做备份时没有备份日志文件，因此在出现故障时，就无法进行恢复。这种功能只可用在在线备份中，通过在调用备份命令时指定 "include logs" 便可以使用这项功能。在恢复期间，日志文件只从备份镜像中提取，如果提供了 LOGTARGET 字段，并且设置了 LOGSONLY 参数，那么只能从备份镜像提取日志文件，而不是从数据库数据中提取。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
  
  
• 在 DB2 Technical Support 可以找到 Version 8 Information Center 和 PDF 产品手册之类的参考资料。
  
  
• DB2 UDB 专区 中包含关于 DB2 UDB for Linux、UNIX 和 Windows 的最新信息，其中有很多文章详细谈到了最新特性。
  

作者简介

		Dale McInnis 拥有新不伦瑞克大学（University of New Brunswick）的计算机科学学士学位以及多伦多大学（University of Toronto）的电子工程学硕士学位。Dale 于 1988 年加入 IBM，从 1992 年开始一直在 DB2 开发小组工作。在此期间，Dale 一直致力于 DB2 内核的开发，包括索引管理、备份和恢复、数据链（datalink）技术，最近还担任了高可用性架构师。

		Paul C. Zikopoulos 拥有 BA 和 MBA 学位，是 IBM Global Sales Support 团队的一名获奖撰稿人和发言人。他有七年以上的 DB2 方面的经验，而且还写了许多关于 DB2 的期刊文章和书籍。Paul 为很多杂志撰写过有关 DB2 的文章，并且与他人合著了以下书籍： DB2 - The Complete Reference、 DB2 Fundamentals Certification for Dummies、 DB2 For Dummies 和 A DBA's Guide to Databases on Linux。Paul 是一位在 DRDA 和 Cluster/EEE 方面获得 DB2 认证的高级技术专家（DB2 Certified Advanced Technical Expert），以及在商业智能和数据库管理方面获得 DB2 认证的解决方案专家。您可以通过 paulz_ibm@msn.com 与他联系。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首