级别： 初级 David Kline, 开发者关系技术支持, DB2 Vendor Enablement，PartnerWorld for Developers
2002 年 7 月 01 日 本文将讨论如何完全自动地将生产数据库转移到开发机器上，从而对最新的生产数据进行测试。本文将帮助您借助 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 脚本中要执行的命令以及对这些命令的解释：
-
rmdir /S /Q G:\backups\PRODDB.0
该命令将删除开发目录 \backups 中的任何数据库映象。如果有两个以上来自同一个数据库的数据库映象位于同一个目录，您就必须指定一个时间戳记（timestamp）值。我们无法在自动化脚本中轻易地完成这一步，所以我们删除了数据库映象。
请注意：为了防止意外删除其它数据库映象，将 \backups 目录只专用于该数据库是很重要的。对于这个操作，您可以考虑使用一个独一无二的目录名。请记住，这是一个开发目录，而不是生产目录。
-
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 ...执行以下命令...
-
db2 "force application all"
在删除开发机器上的旧数据库之前，您必须强制关闭任何应用程序与数据库驻留所在的 DB2 实例之间的连接。目前，我们没有办法自动关闭所有应用程序与一个数据库之间的连接。如果有任何其它依赖于 DB2 实例的服务还在运行，您就必须在停止 DB2 实例之前先停止这些服务。
-
db2 "restore db proddb from C:\backups into devdb redirect without prompting"
恢复过程现在将创建新的数据库 devdb，并表明重定向，允许为表空间指定容器。如果收到了消息 SQL1277N，请不要担心。这条警告消息只是表明可以为表空间定义容器（请参阅
第 3 步）。
上面的 REDIRECT 选项允许我们指定来自生产系统的备用表空间容器路径。如果没有指定 REDIRECT，您就必须创建与生产系统上所示相同的数据库 <盘符>\<实例名>\NODE0000。而如果生产表空间容器位于不同的路径，那您还必须在开发机器上为它们设置路径。
-
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：当前数据库的表空间
Tablespace ID = 0
Name = SYSCATSPACE
Type = System managed space
Contents = Any data
State = 0x0000
Detailed explanation:
Normal
Tablespace ID = 1
Name = TEMPSPACE1
Type = System managed space
Contents = System Temporary data
State = 0x0000
Detailed explanation:
Normal
Tablespace ID = 2
Name = USERSPACE1
Type = System managed space
Contents = Any data
State = 0x0000
Detailed explanation:
Normal
|
Tablespace ID 与数据库中的表空间一一对应，您将用它来对与其相关联的容器进行重定向。您的列表很可能要更长一些，才能包括更多用户定义的表空间。
在上面的 SET 命令中（
第 3 步），Tablespace ID 0、1 和 2 用来指定将被分配新的容器路径的表空间。三个表空间都是系统管理的空间（System Managed Space，SMS），其容器指向 C:\tablespaces 目录。请注意，您只需创建 C:\tablespaces 目录。执行 SET 命令将创建目录 tbspc1、tbspc2 和 tbspc3。如果您有数据库管理的空间（Database Managed Space，DMS），其句法稍有不同。让我们假设还有第四个表空间，它是一个 DMS 表空间。我们将执行类似如下所示的命令：
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 "set tablespace containers for 3 using (file "C:\tablespaces\tbspc3" 50000)"
|
请注意：
路径（path）变成了
文件（file），而您为容器分配的页面数是
50000。请确保您分配的页面数至少达到与生产数据库的页面数相同。如果您的开发机器使用的磁盘比生产服务器用的还少，您还可以在重定向恢复的过程中将多个容器合并为一个容器。
-
db2 "restore database proddb continue" |
这是对数据库恢复进行重定向的最后一个过程。
-
copy /y E:\DB2\NODE0000\SQL00010\SQLOGDIR\*.*
C:\DB2\NODE0000\SQL00002\SQLOGDIR\*.* |
如上所示，我们将日志文件从生产机器复制到开发机器。继续假定您的生产数据库使用在线备份方法，您需要让恢复后的数据库前滚所有日志文件，以确保数据库一致性。有鉴于此，我们需要将所有日志文件从生产机器复制到开发机器，并将它们保存在数据库管理员能够找到的目录路径下。您可以通过执行下面的命令确定日志文件的路径：
db2 "get database configuration for <database name>"
|
查找“日志文件路径”或“修改过的日志文件路径”。您应该在生产和开发服务器上执行上面的命令，来确定要指定的日志路径。
-
db2 "rollforward database devdb to end of logs and stop" |
最后，我们可以在所有日志文件都被复制到开发机器上的 D:\DB2INST\NODE0000\SQL00002\SQLOGDIR 目录之后执行一个前滚操作。前滚日志文件是必须进行的，因为数据库备份是在线执行的。请记住，日志路径应该根据数据库配置文件中指明的路径来确定。
 |
|
其它恢复注意事项
如果您打算将数据库从生产机器转移到开发机器，而数据库没有缺省的代码页 1252（Windows 版），您就需要在执行恢复之前，在开发机器上用正确的代码页创建数据库。如果您没有进行这一步，而您的生产代码页与上面的不同，如 1208，恢复实用程序会假定使用缺省的代码页 1252，并试图将代码页 1208 的数据库恢复到代码页 1252 的数据库中。这将导致产生 SQL2548N 错误。
安排工作
既然我们详细描述了编写脚本的各个步骤，就可以创建一个工作安排，在某天、某星期或某月的特定时间运行备份和恢复操作。我们的策略就是，在运行开发机器上的恢复脚本之前运行生产机器上的备份脚本。在运行恢复操作的几个小时之前就根据生产数据库的大小情况安排备份工作，这样可能是比较有远见的做法。这将确保恢复不会在备份完成之前开始。
让我们使用开发机器作为示例，一步步使用 Script Center GUI 工具创建安排。
- 打开 Control Center。用鼠标左键单击菜单栏上的
Tools并选择
Script Center：
图 1. 选择 Script Center
- Script Center 将被打开。用鼠标左键单击菜单栏上的
Script并选择
Import...。
图 2. 选择 Import
- 选择您的脚本文件所在的
\scripts 目录，然后选择 restore_devdb.cmd。
图 3. 选择 restore_devdb.cmd
-
- 在 Instance 列表框中选择 DB2 实例，数据库在这里被创建。
- 为您选择的脚本输入一个新的脚本名。这只是您在第 3 步中所选的脚本的一个副本，它将用于充当执行脚本。
- 在 Script Description 文本框中提供对脚本的描述。
- 您可以在 Working Directory 文本框中指定希望脚本输出（即错误和警告消息）的地方。
- 确保您选择了
OS command单选按钮，因为我们用的是命令文件。
图 4. Edit Command Script 窗口
- 既然脚本已经就绪，那么我们就可以安排它在某个预先确定的日期运行了。用鼠标右键单击要运行的脚本，并选择
Schedule...。
图5. 选择 Schedule
- 您可以使用这个表单来指定脚本运行一次还是运行多次。
图 6. 指定脚本
确定脚本是否成功
在运行脚本之后，如果能知道脚本是否被成功执行就好了。在从 Script Center 执行脚本时，使用 Journal 来确定脚本是否成功执行是常用的做法。但由于我们正在运行要执行其它 OS 脚本的 OS 脚本，Journal 中将不会显示输出的结果。为了缓解这个问题，您可以将 DB2 消息发送到脚本中的输出。举例来说，在上面的备份脚本中，我们用下面的方式备份数据库：
db2cmd "db2 backup db proddb online to G:\backups"
|
我们可以加入下面的命令，从而让命令的结果可以发送到 backup_results.msg：
db2cmd " "db2 backup db proddb online to g:\backups" > backup_results.msg"
|
这将让我们能够确定命令是否成功。接下来，backup_results.msg 文件将被写入您在创建脚本时指定的工作目录（请参阅
图 4）。
请注意：如果脚本不是在调用另一个命令窗口会话（即 db2cmd），您就不必使用两组双引号。
结束语
将生产数据库转移到开发机器可能会是一个复杂而令人烦恼的过程。本文一步一步地指导您如何创建自己的备份／恢复脚本并让其自动执行，从而在没有用户干预的情况下运行这些脚本，文章的目的是减少该过程中可能出现的隐患。此外，我们还展示了备份和恢复命令与 db2move 以及分离镜像实用程序相比所具有的优势。请注意，每个 DB2 实用程序都各有其用武之地，您可能会发现 db2move 或分离镜像实用程序有时更能满足您的需求。
对于任何重要的数据转移来说，我们都强烈建议您在进行大规模的备份和恢复之前，先使用测试数据库对生产和开发机器执行备份和恢复脚本。而且您没有必要只遵循这里所提供的句法。您还可以在脚本中加入很多其它的 OS 和 DB2 命令，来调整您特定的备份和恢复策略。
希望本文的概念能够使您花更少的时间在转移数据上，而用更多的时间去进行开发。要了解更多关于如何利用 DB2 的数据转移实用程序的内容，请访问下面这些有用的链接：
关于作者 | | | David Kline 是 PartnerWorld for Developers 的一名 DB2 技术支持代表。David 与其他 10 名小组成员一起帮助独立软件供应商（Independent Software Vendor，ISV）解决各种开发和管理问题。David 持有应用程序开发和管理两方面的 DB2 证书。他的多数时间都用在帮助 ISV 解决与 DBA（Database Administration，数据库管理）相关的问题。如果您想进一步了解 PartnerWorld for Developers，请访问
http://www.developer.ibm.com/。
|
对本文的评价
| 
