不同平台DB2数据库之间大批量的移动数据（三）

eagleshi

有那么一次接了一个二手项目，前期管理十分混乱，版本控制做的一塌糊涂，手边的东西是要啥没啥……
检查下手边拥有的东西：数据库备份for aix一个；程序源码一份，看起来挺完整的但不知道是哪个版本的；可执行文件及其运行环境，这个还算厚道，是最新版本的。还好我只是需要完成数据库在Windows平台上的重建工作，要我改程序的话我真是要抓狂了，呵呵。同情那几个可怜的程序员~
嘲笑完别人，现在开始可怜下自己；数据库只有备份for aix的，没有任何创建数据库对象的脚本。“巧妇难为无米之炊”——人世间最痛苦的事莫过于。呵呵！自称为“巧妇”似乎有自夸的味道。
我当时想了下，大体的初步方案是：先把这个数据库恢复在aix平台上，在想办法移植在windows操作系统得数据库上。关于如何在aix下面用命令行恢复数据库我就不在这里多说了，有兴趣的同志们可以看我以前有关数据库备份恢复的篇目。在没有脚本的情况下，当时我能想到是只有去借助ERWin的Reverse Engineer（反向工程）功能去生成数据库的E-R图，然后根据这个E-R图生成数据库对象。生成对象后再利用导入/导出程序来转移数据，数数这个数据库中用户表大约有140个，这么看来工程蛮浩大的样子~
其实用ERWin反向工程做得很快，唯一不好的一点就是生成以后所有的tableview都聚集在工作区的最中央，密密麻麻的一坨，我要把这些tableview一个一个的分开才能看得清楚。而且数据库里面用户定义的触发器、视图等都不太容易导出，需要察看系统表中对触发器和视图的定义语句（SYSIBM.SYSVIEWS, SYSIBM.SYSTRIGGERS）。另外，在整理过程中可能也调整了一下tableview，造成了在导入/导出过程中由于字段顺序不一致的问题被reject记录现象，只能根据字段顺序在导出的时候去指定导出的select语句。这样的话，每一个表都要从数据库里面看字段顺序显得很麻烦；后来于是就做了一个专门的程序来自动读取生成表的所有字段解决了这个问题。按照这个方案我总算完成了此次任务，但我觉得这个方案我不是很满意，因为中间存在太多的人工干预，非常的麻烦。我还要找其他更好的解决方案~
实际上是有其他的方案的，这也在我找到的一本书上得到肯定的答案；有些人甚至都用过的。没错，它们就是DB2Move和 DB2look工具。还是照例来介绍下这两个工具的使用方法吧。
db2move 命令
db2move <database-name> <action> [<option> <value>]
必须指定数据库名（想要移动的表所在的数据库）和要执行的操作（export 和 import 或 load）。然后指定一个选项来定义操作的范围。例如，可以将一个操作限制在特定的表（-tn）、表空间（-ts）、表创建者（-tc）或模式名（-sn）范围内。指定表、表空间或表的创建者的一个子集只对 export 操作有效。如果指定多个值，就必须使用逗号将其分隔开。具体参数使用参考command reference。
db2look命令
db2look -d <database-name> [<options>]
必须指定想要描述对象所在的数据库名。然后指定一个或多个选项（可以以任意顺序）来定义提取的的范围。具体参数使用参考command reference。
有了这两种武器，我决定再作一次试验来捅捅这个在异种平台间迁移数据库的“纸老虎”。
环境准备：IBM P650小型机，安装AIX5操作系统，DB2v8.2 for AIX
普通PC，Windows2003 SP1，DB2v8.2 for Windows（注意，两种环境下的DB2软件版本一定要一致，否则在创建新数据库的表对象有可能会出错。）
步骤一：在 AIX 上，运行db2move，导出 JWDB数据库中所有用户表中的数据。因为此操作会生成大量的数据文件，我的做法是建立一个专门的目录来存放导出文件，以利于后面ftp文件传输。
　　
db2move jwdb export
***** DB2MOVE *****
Action:      EXPORT
Connecting to database JWDB ... successful! Server: DB2 Common Server V8.2.0
EXPORT:   4824 rows from table DB2INST1.ARRCOUPARA
……
Disconnecting from database ... successful!
 
步骤二：在AIX上，运行db2look，为JWDB数据库中的所有对象捕获 DDL 语句，并将输出结果写入一个名为 db2look.ddl 的文件中。 
 
db2look -d jwdb -e -a -o db2look.ddl

  
步骤三：使用ftp登录并下载。请确保使用二进制模式传输db2move.lst 文件和 db2look.ddl 文件。为了方便起见，下载后我把两个文件里面的DB2INST1的模式都去掉了，方便在Windows平台下进行管理。
 
步骤四：在Windows上，创建新的JWDB数据库，然后运行 db2look 工具所生成的脚本创建数据库对象，运行 db2move，将数据从 PC/IXF 文件装载到JWDB数据库中的所有用户表中。
 
db2 -tvf db2look.sql
db2move jwdb load


 
到此为止，迁移工作基本上算是告一段落了。基本上数据转换完毕，剩下的就是检查和收尾的工作了。
 
我于是就随便找个了表，运行下查询看看，发现查询出错。
 
SQL0668N Operation not allowed for reason code "1" on table USERTBL.
SQLSTATE=57016 


这是怎么回事呢？我接着在DB2命令中心查询。
 
 
------------------------------------输入的命令 ------------------------------------------
? SQL0668N;
 -----------------------------------------------------------------------------
 SQL0668N当基础表（或从属表）处于检查暂挂状态时，不允许操作。
 
解释: 当表处于检查暂挂状态时，可能有一行或多行违反了对数据定义的约
束。此表不能用于操作。若从属表处于检查暂挂状态，则对不处于检查暂挂
状态的父表的操作也可能接收到此错误。
 
用户响应: 执行带有 IMMEDIATE CHECKED 选项的 SET INTEGRITY
语句，并确保数据符合对该表或从属于它的表定义的所有约束。

　　看来是处于检查暂挂状态了，我按照提示信息执行以后就可以访问了。
set integrity for usertbl immediate checked
这么看来，在db2move过程中会有些表因为检查约束可能会处于暂挂状态，需要执行SET INTEGRITY命令来恢复它的暂挂状态。
此次迁移任务得试验到这个时候就算是大功告成拉！~谢谢大家的欣赏。

PS：我后来查了下相关资料，可以从系统表中检索处于检查暂挂状态的表信息，命令如下：
Select tabname from syscat.tables where status=’C’