级别: 中级

David Kline

开发者关系技术支持, DB2 Vendor Enablement，PartnerWorld for Developers

2002 年 7 月

本文将讨论如何完全自动地将生产数据库转移到开发机器上，从而对最新的生产数据进行测试。本文将帮助您借助 DB2 的 Script Center GUI 工具使用脚本来执行在线备份。您还将学会如何在开发机器上执行一个脚本来执行重定向恢复，接着执行 rollforward 命令来应用日志文件。本文还将描述恢复的 REDIRECT 选项的方法，还要解释为什么必须进行前滚（roll forward）操作。

引言

将数据库从一个系统转移到另一个系统可能是件非常复杂的工作，特别是在源数据库需要每周 7 天每天 24 小时持续可用的情况下。如果能够只用一步简单的操作来转移所有数据库对象，那不是很好吗？不用设置约束，不用创建索引、表空间或缓冲池？使用 DB2 的备份和恢复实用程序是最简单的转移数据库的方法，没有比它更简单的方法了。

本文将讨论如何将一个可恢复的生产数据库完全自动转移到开发机器上，从而对最新的生产数据进行测试。为了实现这一点，我们将选用一个可恢复的生产数据库，然后借助 DB2 的 Script Center GUI 工具使用脚本来执行在线备份。然后，我们将在开发机器上执行一个脚本来执行重定向恢复，接着执行 rollforward 命令来应用日志文件。接下来，我们会更详细地描述在恢复中使用 REDIRECT 选项的方法，还要解释为什么必须进行前滚（roll forward）操作。

优势

我们可以用很多不同方法来将数据库从一个系统转移到另一个系统。使用 db2move 实用程序可以通过导出（export）和装入／导入（load/import）API 对表进行转移。如果您需要在不同种类的平台之间转移数据库，那么这种方法非常有效。然而，这种方法不会转移其它数据库对象，如触发器、序列、表空间、缓冲池和索引。您必须借助 db2look 实用程序在另外的操作中重新创建这些对象。而对 LOB 表来说，它必须被限制在每个表 26000 行之内。

执行分离镜像（split mirror）是另一种转移数据库的方法。尽管这也是克隆数据库的一种非常有效的方法，但这种方法更加复杂，而且需要存储介质供应商的设备来访问分离镜像。此外，您在开发机器上的数据库目录、表空间容器以及日志文件的目录路径都必须与生产系统上相应的目录路径完全一致。很多情况下，开发机器上甚至没有能够使用的必要盘符以重新产生所需的路径。而且，DB2 服务器的实例也必须具有相同的名称。

DB2 的备份和恢复实用程序会移动数据库中的所有对象，您还可以指定备用路径供表空间容器驻留。在转移数据库时，这会带来最大的灵活性。

请注意： 有些对象，如用户定义函数（user defined function，UDF）和存储在外部的存储过程，因为备份映象中并不包括这些对象，所以必须将它们分开转移。 环境 在后面提供的示例中，我们将使用两台装有 Windows® 的机器，它们通过本地网络互相映射（我们需要两台机器安装相同的操作系统平台）。在我们的示例中，每台机器都装有 DB2 版本 7.2（企业版），并安装了修订包 6。缺省情况下，在安装 DB2 时就包括了控制中心（Control Center），它也是运行脚本中心（Script Center）所需的。 如果您打算使用 UNIX® 环境，那么这些规则同样适用。两台机器必须安装相同的操作系统平台（在 SunOS 和 HP 之间进行恢复时除外），而且必须在备份／恢复过程中通过网络来安装文件系统。此外，缺省情况下并不在 UNIX 上安装控制中心组件。所以我们必须在使用调度程序之前安装控制中心（另一种做法就是通过使用计时程序（cron job）来执行脚本）。 LOGRETAIN 和 USEREXIT 我们要认识到，正在执行的是一个可恢复的生产数据库的在线备份，这一点很重要。由于数据库是可恢复的，所以我们可以假定已经采取了必要的预防措施，以应付数据库变为不可操作的情况。特别是要将 LOGRETAIN 或 USEREXIT 数据库配置参数打开（ON），以便可以进行前滚恢复。为了确定生产数据库是否能够进行恢复，您可以在 DB2 生产服务器中执行下面的命令来进行验证： db2 "get database configuration for <database alias>" 您接下来需要查看 LOGRETAIN 或 USEREXIT 参数是否为 ON。如果这两个参数都没有打开，您就可以考虑参照 IBM's Data Recovery and High Availability Guide and Reference 应用一种高有效性（high-availability）策略了。 请注意：

尽管将一个不可恢复的数据库从生产环境转移到开发环境也是可能的，但本文中不会讨论这个问题。 创建脚本的准备工作 为了小心起见，我们强烈建议您在进行大规模的备份和恢复之前，先使用测试数据库对生产和开发机器执行备份和恢复脚本。如果是这样，您就需要在执行脚本前先创建几个初始目录。您将需要创建下面几个目录： 生产机器 ： \scripts（保存将执行在线数据库备份的脚本） 开发机器 ： \backups（保存生产数据库的备份映象） \scripts（保存将恢复数据库的脚本） \tablespaces（保存表空间容器） 创建备份脚本（生产机器） 下面是 backup_proddb.cmd 脚本中要执行的命令以及对这些命令的解释：

1. rmdir /S /Q G:\backups\PRODDB.0 该命令将删除开发目录 \backups 中的任何数据库映象。如果有两个以上来自同一个数据库的数据库映象位于同一个目录，您就必须指定一个时间戳记（timestamp）值。我们无法在自动化脚本中轻易地完成这一步，所以我们删除了数据库映象。 请注意： 为了防止意外删除其它数据库映象，将 \backups 目录只专用于该数据库是很重要的。对于这个操作，您可以考虑使用一个独一无二的目录名。请记住，这是一个开发目录，而不是生产目录。
2. db2cmd "db2 backup db proddb online to G:\backups" 该命令将执行 DB2 命令窗口会话，并运行数据库备份命令，然后将映象存储到开发机器上。由于我们假定数据库必须每周 7 天，每天 24 小时持续运行，所以进行在线备份是必要的。在上面的实例中，G: 盘符指向开发机器上的 C: 盘。 请注意： 您必须至少进行一次完整的生产数据库离线备份，才能够执行在线备份。

创建恢复脚本（开发机器） 进行恢复要使用两个脚本。第一个脚本将调用一个 DB2 命令窗口会话，并执行第二个脚本，后者将随即执行几个 DB2 和操作系统命令。 脚本 1

\scripts\restore_devdb.cmd ...执行以下命令...

db2cmd restore_devdb_2.cmd

脚本 2

\scripts\restore_devdb_2.cmd ...执行以下命令...

1. db2 "force application all"

   在删除开发机器上的旧数据库之前，您必须强制关闭任何应用程序与数据库驻留所在的 DB2 实例之间的连接。目前，我们没有办法自动关闭所有应用程序与一个数据库之间的连接。如果有任何其它依赖于 DB2 实例的服务还在运行，您就必须在停止 DB2 实例之前先停止这些服务。

   
   

2. db2 "restore db proddb from C:\backups into devdb redirect without prompting"

   恢复过程现在将创建新的数据库 devdb，并表明重定向，允许为表空间指定容器。如果收到了消息 SQL1277N，请不要担心。这条警告消息只是表明可以为表空间定义容器（请参阅 第 3 步）。

   上面的 REDIRECT 选项允许我们指定来自生产系统的备用表空间容器路径。如果没有指定 REDIRECT，您就必须创建与生产系统上所示相同的数据库 <盘符>\<实例名>\NODE0000。而如果生产表空间容器位于不同的路径，那您还必须在开发机器上为它们设置路径。

3. db2 "set tablespace containers for 0 using (path "C:\tablespaces\tbspc0")" db2 "set tablespace containers for 1 using (path "C:\tablespaces\tbspc1")" db2 "set tablespace containers for 2 using (path "C:\tablespaces\tbspc2")"

   为了自动进行恢复过程，我们将在开发机器上设置新的容器路径，对与生产数据库相关联的所有表空间进行重定向。为了确定数据库中驻留着哪些表空间，您必须先连接到生产数据库，并在 DB2 命令窗口执行下面的命令：

   db2 "list tablespaces show detail"

   输出应该类似于如下所示：

   样本 1：当前数据库的表空间

   1 2 3 下一页