中华网络安全联盟    作者：佚名    来源：网络转载    时间：2006-3-23

本文描述了在开放系统上使用 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 的示例。