DB2日志传送基础知识简介

本文描述了在开放系统上使用 IBM® DB2® Universal Database™ 时配置日志传送的概念和实现。由于数据库系统对于企业成功变得越来越重要，对于全天不间断(24x7)可用性的需求也就变得前所未有地强烈。一种常见的提供 99.99%(或“四个九”)可用性的方法是实现“热”备用数据库服务器。使用备用服务器并不是个新概念;数据库管理员(DBA)们已经使用该方法多年了。通常，备用服务器需要 DBA 或操作员手工创建主系统上数据库和日志的备份，然后定期地将这些备份恢复到备用服务器上。如果主服务器发生故障，则宕机时间仅限于处理自从将最近一次备份恢复到备用服务器以来的日志文件所需的时间量。

备用服务器故障转移通常并不是自动的。相关人员必须确定启用备用服务器所花费的时间是否少于修复主系统上的原始故障所花的时间。

日志传送是什么?

日志传送(log shipping)是一种方法，它自动从主 DB2 服务器备份事务日志，并使该备份自动对备用服务器可访问。一旦将日志文件放到了备用服务器上，它就可以保持与主服务器的相对同步。

为什么要花费力气实现日志传送?

日志传送有什么好处，您为什么要花费时间设置它呢?日志传送提供了下列优点:

无需昂贵的软件或硬件即可实现冗余故障转移系统。无论从硬件还是软件角度来看，主服务器和备用服务器不必相同。备用服务器可以用于其它用途;而不必长期闲置。例如，当辅助数据库因处理进入的日志文件而处于不可访问状态时，可以在备用服务器上运行另一个独立数据库。

一旦设置好，配置成本相对低廉并且易于维护。

有非常可靠的方法用于提供数据库的冗余副本。

由于数据库处于前滚方式，因此它提供了热备用，热备用使数据库启动，并且已经准备好数据高速缓存。

能够被配置成当故障出现时允许极少量的数据损失(如果有数据丢失的话)。

实现和维护配置的成本相对低廉。

支持本地位置和灾难(远程)方案。

有没有局限?

日志传送有一些局限。与 HACMP 或 Veritas Cluster 那样的系统不同，它不提供完整的功能。但是，它也不需要额外的硬件或软件。这可以归结为一个权衡成本与可用性及复杂性的问题。对于大多数需要冗余系统，但在故障转移方案期间可以接受一些数据丢失的客户而言，日志传送是一种实用的解决方案。

只有使用附加软件，才能使日志传送彻底自动化。DBA 或操作员仍然必须在发生故障时手工地将主服务器的功能转移到备用服务器;但可以为这个故障编制脚本以最大限度地减少人为干预。用户被中断的时间，等于重播一个或多个日志文件并从任何不完整的事务回退所需时间的总和，外加重新连接用户的应用程序所需的时间。使备用数据库联机所需的时间取决于该备用服务器处理进入的日志文件的频率，以及日志文件的大小。

一旦将数据库切换到备用服务器，就必须更改客户机应用程序，使它也能指向新的服务器。或者，您可以转移该服务器的主机名和 IP 地址。

操作方面的考虑事项

何时重新初始化备用数据库

在 DB2 上重建索引时，会将一条日志记录写入日志，以表明该操作已启动。当备用数据库处理这条日志记录时，它不会在备用服务器上自动重建该索引。(通过设置数据库管理器 INDEXREC 配置值)可以将 DB2 配置为在其脱离前滚暂挂状态(例如，接管时)之后，第一次连接到数据库就重建索引，或者配置为在第一次尝试访问索引时进行重建。无论使用哪种方法，在发生系统故障转移时，最终用户都会察觉性能下降。防止这种情况的方法之一，是从主数据库的备份映像重新填充备用数据库，或者在重建索引时使用 I/O 暂挂和分离镜像技术进行刷新。

在主数据库上运行 DB2 装入实用程序会影响备用数据库服务器。当调用 LOAD 命令时，可以选择让装入实用程序制作所装入的表空间的备份映像，或者将备份映像的创建延迟到将来某个时间。如果选择让装入实用程序创建备份映像，则备用服务器必须有权访问装入实用程序所用的目标设备。如果选择以后再进行备份，或者在重播装入日志记录时备份映像不可用，那么备用服务器会将被装入的表空间置于恢复暂挂状态。在两种情况下，您都应该在装入操作完成后刷新备用数据库，以确保在需要进行故障转移的情况下，备用服务器上的所有数据都是可访问的。

先决条件

以下是在 DB2 上设置和配置日志传送之前必须满足的先决条件:

主系统和备用系统都必须运行同一版本的 DB2。可以故障转移到备用服务器以便在主系统上安装 DB2 的新修订包;但是，版本必须相同或更高。不能使用这种方法“回退”到某个修订包，因为两个系统不仅必须运行同一级别的 DB2，而且还必须运行同一级别的操作系统。

备用系统可用于数据库和日志文件的磁盘空间必须至少和主系统的一样多。您必须考虑在故障转移到备用服务器时，主服务器可能几天都无法使用的可能性。

必须在备用服务器上配置主服务器为数据库维护而运行的所有自动化进程。DB2 只允许为每个实例配置一个用户出口程序。如果备用服务器上已经有一个活动的数据库，那么它使用的 DB2 实例应该独立于主系统的 DB2 实例。

备用服务器上的日志归档目标必须可访问。在故障转移之后，必须保存日志文件，以便使主数据库能够恢复联机， 必须在备用系统上恢复完整的数据库备份，以初始化热备用。在创建该备份之后，主系统上生成的所有日志文件也是必需的。

有哪些选项可用?

用 DB2 实现日志传送有多种方法。本文讨论了一些较为流行的方法。

在所有情况下，备用服务器都需要一个定期发出 db2 rollforward db to end of logs 命令的调度作业。这个命令运行的频率决定了在故障转移情形下使备用服务器可用的速度。

这种频率还可以用作保护数据库不受应用程序错误破坏的方法。例如，如果备用服务器一直保持比主服务器落后几小时的状态，一个应用程序破坏了数据库中的数据，那么可以将数据库故障转移到备用服务器，以“回退”毁坏的数据，而对用户影响却很小。

所有日志传送配置都是用用户出口程序实现的。这是唯一可以用来在 DB2 中管理日志文件的方法。当一个日志文件满了的时候，DB2 记录器就将它归档。然后由 db2uext 可执行文件负责处理该日志文件。

日志传送是否有不同的类型?

日志传送有两种方法。在 拉出方法中，备用服务器在需要时从中央共享位置(如日志归档目标)拉出日志文件。在 推方法中，主服务器确保当它归档主日志文件时使这些日志文件驻留在备用服务器上。

DB2 将日志文件归档到用户出口程序 db2uext2 所指定的目标目录中。该用户出口程序的样本位于 DB2 实例目录 sqllib/samples/c 中。其中包括了用于磁盘、磁带和 Tivoli? Storage Manager 的示例。

拉出方法

拉出方法涉及配置主系统上的用户出口程序，以将日志文件归档到主服务器和备用服务器都有权访问的目标设备上。备用服务器不会收到日志文件已归档的通知，而且必须检查归档目标路径。可以通过使用 db2uext2.cdisk 或 db2uext2.cadsm (在 DB2 未来的版本中将重命名为 db2uext2.ctsm )样本用户出口程序来做到这一点。用户出口可执行文件必须位于主系统和备用系统的缺省 DB2 实例路径中。

当在备用服务器上调用前滚数据库命令时，DB2 记录器自动尝试从归档目标路径中检索下一个连续的日志文件。前滚操作持续检索日志文件，直到再没有需要处理的文件为止。

推方法

使用推方法，可以修改用户出口程序，将日志文件复制或 FTP 到备用服务器的活动日志路径或在备用服务器上可以访问的溢出日志路径。可以通过修改 db2uext2.cdisk 样本程序，将备用服务器的日志路径指定为目标来实现这一点。

当在备用服务器上调用 roll forward db 命令时，DB2 记录器自动尝试从归档目标路径检索下一个连续的日志文件。前滚操作持续检索日志文件，直到再没有需要处理的文件为止。

如何设置?

无论使用拉出方法还是推方法，大部分设置过程都与下面所说明的步骤类似:

将数据库配置为启用用户出口程序和日志归档。做完这一点之后，数据库将处于备份暂挂状态。这个备份映像将成为恢复的初始起点，应该将它保留到执行下一次完整数据库备份为止。

将用户出口可执行文件置于 DB2 实例缺省搜索路径中的某个位置。DB2 用户出口程序的样本源代码模块位于 DB2 实例 sqllib/samples/c 目录中。它们是:

Db2uext2.cadsm — 对 Tivoli Storage Manager 的支持，也称为 ADSM

Db2uext2.cdisk — 对磁盘的支持

Db2uext2.ctape — 对本地磁带的支持，仅可用于 UNIX? 系统

Db2uext2.cxbsa — 对 XBSA Draft 0.8 客户机的支持

这些样本程序中的每个都只需要稍作修改(如 buffer_size 、 audit_log_activation 、 audit_log_path 、 error_log_activation 和 error_log_path )。每个样本程序都包含一旦完成修改就必须发出的准确的编译语句。

也有一些第三方供应商(如 Veritas、Legato 和 SAP)提供他们自己的 DB2 用户出口二进制代码，所有这些都可以用来实现日志传送。

初始化备用服务器的数据库。可以通过(联机或脱机)恢复主服务器的完整 DB2 备份映像，或者通过使用分离镜像副本来做到这一点。有关使用分离镜像副本的详细信息将在下面描述。在这两种情况下，备用数据库的硬件都不必与主数据库的硬件相同。处理器和磁盘的个数和大小都可以完全不同。唯一的限制是备用数据库上每个表空间的大小至少要和主数据库上的一样大。这是为了防止出现这样的情况:备用系统的空间已经用尽，而主系统仍在继续增长。如果物理磁盘布局不同，那么就需要进行重定向恢复来初始化备用数据库。

在备用系统上配置调度作业以便定期发出 db2 rollforward to end of logs 命令。这样会处理从主服务器接收的日志记录，并使其备用服务器的日志保持最新。

现在备用服务器已经就绪。

如果“四个九”不够好，那该怎么办呢?

有许多办法可确保在日志传送配置中做到零数据丢失。但是，需要额外的配置和/或硬件。让我们研究一些实现无数据丢失备用服务器的较流行的方法。

通过建立镜像进行日志传送

确保无数据丢失的方法之一是制作用于包含日志文件的卷的镜像。可以使用操作系统的磁盘/卷镜像功能来实现这种方法。使用这种方法时，写入主数据库的每条日志记录也会被写入备用数据库。每条日志记录都被写入到这两个系统中，这样确保了无数据丢失。这种方法的缺点在于与两次磁盘写入操作相关的性能成本，其中一次写入操作有可能是远程的。

通过双记录进行日志传送

另一种避免数据丢失的方法是利用 DB2 的双日志记录功能。当使用这种功能时，DB2 将同一日志记录写入到两个地方。这两个地方中的一个有可能是远程安装的文件系统。DB2 试图将每条日志记录写入到两条日志路径。如果其中一条路径发生错误，则将错误消息记录到 db2diag.log 文件，而处理将继续进行。如果对其中一条路径的写入操作失败，那么除非活动日志文件已满，否则 DB2 不会尝试再向该路径进行写入操作。DB2 也不会在重新建立连接之后再次同步这两个日志路径。仅当主系统和备用系统之间的网络连接高度可靠时，这种方法才是可行的。

利用智能存储系统

现在，有许多智能存储系统(如 IBM ESS、EMC 和 HDS)可供使用，它们为本地或远程存储系统提供了磁盘镜像能力。这些系统中的每一个都提供了制作文件系统镜像的同步或异步方法。有了智能存储系统，主系统和备用系统之间日志文件镜像的实现就会得到极大的简化并且十分可靠。

结束语

总之，日志传送是提供冗余故障转移系统的相对简单和廉价的方法。它易于设置和维护，并可用来支持本地位置和远程位置两种情形。这种灾难恢复方法不会增加现任数据库管理员的负担，因为一旦完成设置，它可以自动运行。

查看本文来源