Q复制是DB2复制技术中较新的一种技术，通过将Websphere MQ引进到复制体系结构中，可以使得复制更加可靠、稳定和快速。本文将通过一个完整的例子来说明如何搭建基本环境，以及如何进行操作，从而实现远程Q复制。
本文将大概讲述SQL Replication，然后引出Q Replication的意义。本文档通过位于两台不同主机上的数据库间的单向复制来展现远程Q复制的使用。除了说明操作步骤以外，本文档同时也对相关的关键概念，一些常见的错误以及相关的信息做出了相应解释。
在实际操作之前，读者应该具有DB2数据库的相关管理操作的基本概念和基础知识，同样也应该对Websphere Information Integrator和Websphere MQ有相关了解。如果读者原来在一个机器上做过DB2复制相关的练习，例如IBM提供的T3练习，将对本文的学习很有帮助。
本文档主要分为三个大部分：第一个部分是配置和编目远程数据库，第二个部分是配置Websphere MQ的相关对象，第三个部分是通过Replication Center来建立起最终的复制环境。对于每一个部分，都包括操作步骤，相关问题和解决办法，以及一些相关的提示信息。
 
|
|
1． 平台的选择
考虑到大部分读者可能更容易获得Windows操作系统环境，所以，本文档的实现，源数据库和目标数据库是分别在两个Windows操作系统上。但是，实际上如果换成其他操作系统平台，如Unix/Linux，所有的操作步骤将是大同小异。
2． 软件的安装
读者需要安装好DB2，Websphere MQ。依据相关安装文档执行即可。
3． 本文的相关约定
为了便于读者学习和实践本文，下面给出了笔者在实际操作过程中所建立起来的环境的具体信息，读者当然也可以对自己的相关机器和对象指定其他的名称。在本文中，所使用的对象信息即如下所述（主要包括主机的设置，DB2的设置，以及Websphere MQ的设置）。
4． 主机和DB2的相关设置信息
注意: 在使用复制功能之前，数据库ITARGET和SAMPLE都应该将日志模式设置为archive logging模式（归档日志模式）。
5． Websphere MQ的相关配置信息
6． Q复制的配置信息
注意: 1. 上面的Replication q map name可以由用户自行定义，一般可以按照复制的功能特点来进行命名。
2. 对于本文中所使用到的相关的MQ的完整定义，可以在EAST_QUEUE_DEFINE.TXT文件和WEST_QUEUE_DEFINE.TXT文件中找到。读者也可以使用上述脚本来生成所需要的MQ对象。
|
|
|
操作步骤
本文中，SAMPLE数据库是源数据库，源表即在这个数据库中。而数据库ITARGET为目标数据库。而对于要创建的MQ对象来说，名字中的EAST和WEST也将用来区分两个主机，EAST相关的MQ对象和ITARGET数据库在同一个主机上，而WEST相关的MQ对象和SAMPLE数据库在同一个主机上。所以，数据将是从SAMPLE（WEST）复制到ITARGET （EAST），其间通过定义好的相关队列来实现数据的中间传递作用。
在EAST端（即Apply Server端，也就是ITARGET目标数据库端），通过下面的操作步骤来编目位于另外一个主机上的SAMPLE源数据库。
1．打开CLP，输入下面的命令来实现对远程SAMPLE数据库的编目：
db2 catalog tcpip node WEST remote 9.181.135.61 server 50000 db2 catalog database SAMPLE at node WEST db2 terminate; |
2．在CLP中输入下面的命令来测试从EAST到WEST的连接是否有效：
db2 connect to SAMPLE user administrator using *** db2 terminate; |
在上述步骤中，可能会遇到一些错误，笔者将其总结在下面的部分，你也可以通过本文后面的参考信息获得更多帮助。这样，一个远程数据库的编目操作就完成了，用户便可以通过CLP命令行方式或者DB2的控制中心图形界面方式来实现对远程数据库的操作。
对于Q复制中的单向复制来说，上述编目步骤即可。如果想实现Q复制中的双向复制或者P2P复制，那么需要在另外一端完成类似上述的步骤，操作方式如下。
在WEST节点（即SAMPLE数据库所在的主机）上，执行如下的操作：
1．打开CLP，输入下面的命令来实现对远程ITARGET数据库中的编目：
db2 catalog tcpip node EAST remote 9.181.135.238 server 50000 db2 catalog database ITARGET at node EAST db2 terminate; |
2．在CLP中输入下面的命令来测试从EAST到WEST的连接是否有效：
db2 connect to ITARGET user administrator using xxx db2 terminate; |
步骤注解
在本部分过程中，我们会经常用到如下一些有用的命令，写在这里，仅供参考: （用户可以修改粗体部分以符合自身需要）
1) db2 list node directory
2) db2 list node directory show detail
3) db2 catalog tcpip node WSII remote 9.181.139.155 server 50000
4) db2 catalog database source at node WSII
5) db2 terminate
6) db2 list database directory
7) db2 create database database_name
8) db2 drop database database_name
9) db2sampl -k （该命令用来创建DB2缺省的SAMPLE数据库，参数k表示建立带有主键的表，如果没有该参数，所有表将没有主键和索引）
10) db2ilist (list instance)
11) db2 uncatalog database database_name
12) db2 uncatalog node node_name
注意: 远程数据库可以被编目，被编目的数据库也可以删除这种编目关系，但是数据库不能在远端被创建和删除。
一些重要的概念：
db2c_DB2
在命令"db2 catalog tcpip node WSII remote 9.181.139.155 server 50000"中，其中的参数50000，不仅可以用这种端口的数字形式，也可以用一个叫做db2c_DB2的服务名称。
db2c_DB2主要实现DB2的网络服务功能。db2c_DB2和数字端口之间的关系实际上可以在dbm cfg文件中找到。
使用"db2 get dbm cfg"命令并查看如下部分：
TCP/IP Service name (SVCENAME) = db2c_DB2 |
因为dbm在DB2实例级别对相关参数进行设定，所以，上述的SVCENAME即是一个定义TCP/IP服务端口的实例级别的参数，其缺省值为50000。
另外，如果是在类UNIX系统中，在etc/service目录下，在services文件中包含了当前DB2所使用到的相关端口信息，可以通过修改这个文件来进行相关修改和设定。下面即是相关内容的截取。
DB2_DB2 60000/tcp
DB2_DB2_1 60001/tcp
DB2_DB2_2 60002/tcp
DB2_DB2_END 60003/tcp // These ports reserved for
DB2 Fast Communications Manager
db2c_DB2 50000/tcp // this is the connection port for instance DB2
|
Codepage:
因为笔者在操作的过程中，曾经试验过一个是中文操作系统，另外一个是英文操作系统的情况。在上述情况下，会发生所谓的codepage不兼容的问题（这个问题在下面的"出错分析及解决"有进一步说明）。Codepage就是指DB2的语言的版本。一般来说，如果操作系统是中文的话，那么DB2自动安装成为中文版本，如果操作系统是英文的话，那么DB2自动安装成为英文版本。尽管如果源数据库和目标数据库的codepage不一样，用户仍然可以成功地从源数据库连接到目标数据库（即connect命令仍然可以成功运行），但是如果没有定义恰当的转换表（用来转换两个不同数据库之间的codepage的表），在复制的时候错误将不可避免。为了简单起见，在本操作实践过程中，两个数据库都是使用的同样的codepage。需要提及的是，codepage可以在创建该数据库的时候为其指定。
关于codepage和数据库链接方面的进一步信息，请参考如下网址：
http://www.ibm.com/developerworks/cn/db2/library/techarticles/dm-0506chong/
http://chinaunix.net/jh/22/16779.html
出错分析及解决
问题1描述：
SQL30081N 检测到通信错误。正在使用的通信协议："TCP/IP"。正在使用的通信API： "SOCKETS"。检测到错误的位置："9.181.139.155"。检测到错误的通信函数："connect"。协议特定的错误代码："10060"、"*"、"*"。 SQLSTATE=08001
分析：
这个错误的原因通常是网络连接不稳定造成的。
解决：
检查并确保源数据库所在的主机和目标数据库所在的主机之间的网络连接可用，并且端口正确。在很多情况下，网络病毒导致网络不可用是需要首先检查的方面。
问题2描述：
SQL0332N 没有从源代码页 "1252" 至目标代码页 "1386" 的转换。原因码为 "1"。
SQLSTATE=57017
分析：
这个问题主要是由于本地数据库和远程数据库的代码页（codepage）不一致造成的。比如本地数据库是代码页为1386的中文版本，而远程数据库是代码页为1252的英文版本，这样可能会产生一些意外的错误。
解决：
通过如下命令来检查代码页的相关设置：（红色字体可以由用户指定）
db2 get db cfg for clientdb (检查clientdb所使用的代码页)
db2 get db cfg for serverdb (检查serverdb所使用的代码页)
db2set (检查当前数据库系统所使用的代码页)
通过如下命令来改变本地DB2数据库系统的代码页：
db2set db2codepage=serverdb codepage (e.g. "1252") db2 terminate |
可以通过如下简单的命令来核对上述修改是否成功：
db2 connect to source user administrator using passw0rd // source是 远程数据库服务器 |
如果source数据库和target数据库可兼容，那么该命令可以成功返回。
操作步骤
1. 本文附件提供了一些脚本来创建相关的MQ对象，用户可以通过修改或者直接使用它们来创建出必要的MQ对象。EAST_QUEUE_DEFINE.TXT文件是用来创建QM_EAST相关的消息对象，WEST_QUEUE_DEFINE.TXT文件是用来创建QM_WEST相关的消息对象。上述两个脚本，里面都定义了queues、channels，以及queue managers等对象。请注意，上述文件定义的对象，实际上是用来做bidirectional的Q复制，对于本文的单向复制而言，只需要用到其中的一部分即可。
2. 在Server A上，定义名叫QM_EAST 的MQ manager。
如果QM_EAST已经存在，按照如下步骤删除旧的QM_EAST：
(1) endmqm QM_EAST
(2) endmqlsr （停止queue manager 的listener，也可以通过MQ services的start/stop 完成。）
(3) dltmqm QM_EAST
然后通过下面的步骤来创建之：
(1) crtmqm -q QM_EAST
(2) strmqm
(3) runmqlsr -t tcp -p 1451
(4) runmqsc QM_EAST<EAST_QUEUE_DEFINE.TXT （需要再开一个cmd运行之）
EAST_QUEUE_DEFINE.TXT在附件中可以找到。
3. 在Server B上，定义名叫QM_WEST的MQ manager。步骤和2类似。
如果QM_WEST已经存在，按照如下步骤先删除之：
(1) endmqm QM_WEST
(2) endmqlsr
(3) dltmqm QM_WEST
然后再创建之：
(1) crtmqm -q QM_WEST
(2) strmqm
(3) 在MQ Services的控制面板中，选择QM_WEST，右键单击，然后选择new->new listener， 然后添加一个listener（TCP，端口1451），并确保该listener运行正常。
(4) runmqsc QM_WEST<WEST_QUEUE_DEFINE.TXT
EAST_QUEUE_DEFINE.TXT在附件中可以找到。
注意：QM_EAST和QM_WEST 的listener端口可以任意指定可用的端口，它们可以相同，也可以不相同。这里，我们将QM_EAST和QM_WEST 的端口分别指定为1450和1451，以示区别。
上面讲述了创建相关MQ对象的步骤，下文将对如何测试MQ对象（如MQ channels和queues等）是否正常工作进行详细讲解。
测试WSMQ对象的连接性
在定义好WSMQ对象之后，用户可以先对其连通性进行测试，以确保后面的步骤可以正确进行。主要可以从如下方面进行测试：
1. 通过MQ Explorer来检查channels连接的有效性.
(1) 在QM_EAST所在的主机上，打开MQ Explorer，启动QM_EAST，那么在"channels"->"advanced"里面，将可以看见EAST_TO_WEST和WEST_TO_EAST两个channel。
(2) 用户可以右键点击EAST_TO_WEST并选择start启动之，然后可以选择Status选项来查看其是否正常运行。
(3) 如果status是"running"，表明channel运作正常。
(4) 如果status是"binding"，表明channel正在绑定监听端口，稍后将有可能开始处于正常运作状态。这种情况下，稍等片刻并再次检查其状态，如果仍然是处于"binding"的状态，那么停止并重新启动。
(5) 如果status是"retrying"，表明当前channel不能正常运作，这个通常是由于网络原因造成的。检查网络状况，例如通过ping程序来检查网络是否有问题，防火墙有时也可能导致MQ channel的retrying状态；检查远端的queue manager (这里是指QM_WEST)是否已经启动，其listener是否运作正常，并且检查CCSID是否一致。如果远端的QM_WEST没有启动，那么status很有可能就是retrying的状态。所以应该检查QM_WEST，保证其处于正常状态，然后在QM_EAST中停止EAST_TO_WEST 这个channel并重新启动之。这些步骤之后，应该能解决上述问题。
对于WEST_TO_EAST这个channel，在QM_EAST，用户可以检查其状态但是不能启动或者停止它，它只能被发送方启动或者停止。用户应该在QM_WEST端启动或者停止它。
2. 通过CLP方式来检查channels的连接性并获取更多相关信息有时候，通过命令行方式可以高效快捷地检查一些相关的信息，这种方式可以脚本化，当我们要检查的channel很多时，或者相关操作重复性比较大时，应该考虑命令行方式来做。另外，命令行方式能够获取更多的出错方面的详细信息。
(1). 在EAST上运行如下命令：
runmqchl -c EAST_TO_WEST -m QM_EAST |
如果没有错误信息显示，表明该channel成功运行。之后打开另外一个命令行窗口，并输入如下的命令：
runmqchl -c WEST_TO_EAST -m QM_WEST |
如果此时返回相关错误码，那么对其进行分析并根据错误提示去采取相应的解决办法。
(2). 测试本地的queues 在EAST上，执行如下命令将一个消息放到队列上：
/usr/mqm/samp/bin/amqsput EAST_RESTARTQ QM_EAST Sample AMQSPUT0 start target queue is EAST_RESTARTQ This is a test message to a local queue Sample AMQSPUT0 end |
然后通过执行下面的命令来从queue中获取信息。这个时候应该会显示出上面输入的消息文本。
/usr/mqm/samp/bin/amqsget EAST_RESTARTQ QM_EAST Sample AMQSGET0 start message <This is a test message to a local queue> no more messages Sample AMQSGET0 end |
在WEST端，执行如下命令来将一个消息放到队列里面：
/usr/mqm/samp/bin/amqsput WEST_RESTARTQ QM_WEST Sample AMQSPUT0 start target queue is WEST_RESTARTQ This is a test message to a local queue Sample AMQSPUT0 end |
同样的，执行如下命令来从queue中获取信息。这个时候应该也会显示出上面输入的相关消息文本。
/usr/mqm/samp/bin/amqsget WEST_RESTARTQ QM_WEST Sample AMQSGET0 start message <This is a test message to a local queue> no more messages Sample AMQSGET0 end |
(3). 测试远程的queues 测试从远端的queue上面放入和取出消息。
在EAST上执行如下命令来将消息放入到WEST_ADMINQ这个队列中。
/usr/mqm/samp/bin/amqsput WEST_ADMINQ QM_EAST Sample AMQSPUT0 start target queue is WEST_ADMINTQ This is a test message to a remote queue Sample AMQSPUT0 end |
在WEST中执行如下命令获取来自WEST_ADMINQ 队列上的消息。
/usr/mqm/samp/bin/amqsget WEST_ADMINQ QM_WEST Sample AMQSGET0 start message <This is a test message to a remote queue> no more messages Sample AMQSGET0 end |
步骤注解
Remote queues:
Remote queues是一个相对的概念，是用来在另外一个queue manager上定义local queue。在本文中，每个queue manager分别定义了两个remote queue。在QM_EAST上，WEST_ADMINQ和EAST_TO_WEST_Q被定义成为remote queue。在QM_WEST上，EAST_ADMINQ和WEST_TO_EAST_Q被定义成为remote queue。
WSMQ objects:
关于MQ对象的更多信息，请参考《Fast Track implementation scenarios》的附录A。该资料在附件中已给出。
出错分析及解决
问题1描述：
C:\Documents and Settings\Administrator>runmqchl -c EAST_TO_WEST -m QM_EAST 5724-B41 (C) Copyright IBM Corp. 1994, 2002. ALL RIGHTS RESERVED.
2005-09-25 17:46:56 通道程序已启动。
2005-09-25 17:47:04 AMQ6047: 不支持转换。
2005-09-25 17:47:04 AMQ9999: 通道程序异常终止。
分析：
在MQ消息手册中查找关于AMQ6047的相关信息，如下：AMQ6047 Conversion not supported.
Explanation: WebSphere MQ is unable to convert string data tagged in CCSID &1 to data in CCSID &2.
User Response: Check the WebSphere MQ Application Programming Reference Appendix and the appropriate National Language Support publications to see if the CCSIDs are supported by your system.
这个错误的原因是由于两个queue manager的CCSID 的设置不兼容造成的。而这种不兼容的最根本原因是由于本地的locale和远程主机的locale不一致造成的（从而WebSphere MQ的安装语言版本不一样）。这点和DB2的code page问题很类似。
解决：
(1) 在MQ explorer中找到CCSID及相关属性。在笔者的环境中，如果安装的是中文版的MQ，那么CCSID的缺省值是1381，而英文版的则相应为437。在这两者之间，它们并没有直接的转换方式来进行兼容性处理。
(2) 由于(1)，我们必须在本地对CCSID进行转换。在EAST(CCSID=1381)端通过如下命令来实现其转换：
strmqm runmqsc display qmgr // 检查当前queue manager的CCSID值 alter qmgr ccsid(437) end |
第三部分 通过Replication Center图形界面建立远程Q复制
操作步骤
这部分主要通过GUI图形界面（即Replication Center）来完成。同时，为了方便起见，其中也会用到CLP命令行方式。对于本文的单向复制而言，这里主要通过配置EAST端来说明相关使用方法。
在开始配置Capture和Apply之前，首先应该对密码和连接性进行测试。在Replication Center中，选择Manage Password and Connectivity，然后选择Systems，在其中添加两行信息，即本地EAST和远程WEST的相关密码和连接信息。
对于远程Q replication图形界面方面的基本操作，大体和完全在一个机器上的Q replication类似，主要的区别在于对MQ相关对象的操作上有所不同。所以下面的操作部分重点在于MQ的详细介绍。
1．建立Q Capture相关的控制表
通过前面的步骤，这里至少可以有两个DB2 server可用，一个是Server A，一个是Server B。可以使用如下命令来获取相关信息：db2 list db directory
具体操作步骤如下：
- 选择Sample作为Capture Server。
- 将Q Capture的Schema指定为ASN。
- Q Manager选择为QM_WEST，然而admin queue应该为WEST_ADMINQ并且restart queue为ST_RESTARTQ。
- 在完成上述配置后，Sample这个Capture Server应该能够用来进行复制了。
2．建立Q Apply相关的控制表
- 选择ITARGET作为Apply Server。
- 将Q Apply的Schema指定为ASN。
- Q Manager应该为QM_EAST。
3．建立Replication Queue Maps
- 在Sample节点下，选择"create Replication Queue Maps"。
- 选择Apply Server为ITARGET。
- 因为前面我们选定了WEST_ADMINQ作为Sample这个Capture Server的AdminQ，所以，Apply server的admin queue也应该同样指定为WEST_ADMINQ。同时，应该指定send queue和receive queue为WEST_TO_EAST_Q。
- 为 Queue map指定一个名称。
4．建立复制预订集
- 从Sample节点，选择"create Replication Subscriptions"。
- 选择"unidirectional replication"。
- 选择ITARGET作为目标服务器，并且使用前面所建立的Queue map。
- 从Capture Server中选择恰当的源表。
- 对于目标表等其他方面的设置，使用缺省值。
- 完成预定集的建立。
5．建立Apply所需要的password文件
- 在目标系统中将当前路径转到apply_path上。
- 输入命令"asnpwd init"。
- 输入命令"asnpwd add alias SAMPLE id administrator password ***"。这样就会生成一个相应的password文件。
6．启动Q Capture程序
设定相关参数，启动Q Capture。
7．启动Q Apply程序
设定相关参数，启动Q Apply。
步骤注解
1. 当在Replication Center中配置password和connectivity的时候，它会要求指定Directory ，这应该是DB2安装目录下的bin目录所在的路径，如"c:\sqllib\bin"。
2. 当在Replication Center中配置password和connectivity的时候，远程主机名字应该正确指定。实际上，在这里IP地址也可以和远程主机名字同样被使用。
3. 在设置复制环境的时候，记得将Capture Server所在的数据库设置为archive logging模式。
4. Password文件在如下情况下是必须的：
a. 当Q Apply需要使用export来导出数据时
b. 当Q Capture需要连接到多个数据库分区时
c. 当需要建立相应的Alert Monitor时
d. 当需要运行Q Analyzer（该程序需要连接到被分析的Q Capture和Q Apply）时
e. 当需要用到TDIFF工具时
5. 关于Dead Letter Queue，可以参考《Fast Track Implementation Scenarios》中的Appendix C. Dead letter queues in a Q replication environment
出错分析及解决
问题1描述：
Capture可以正常启动，但是Apply不能正常启动，处于presume stopped的状态。Receive queue正常运作，subscription处于"inactive"的状态，MQ channels正常运作。
分析：
这个问题很有可能是网络原因造成的，例如IP设置错误等等。
解决：
保证网络正常连接，设定正确的IP地址等等。
问题2描述：
在apply日志中，有如下信息：
2005-10-14 12:12:49.578000 ERROR ASN7551E "Q Apply" : "ASN" : "BR00000" : The Q Apply program detected a gap in message numbers on receive queue "WEST_TO_EAST_Q", replication queue map "SAMPLE_ASN_TO_ITARGET_ASN". It read message ID "51524550434D6AB0000000000000000000000000000003F0", but expected to find message ID "51524550434D6AB000000000000000000000000000000001". The Q Apply program cannot process any messages until if finds the expected message.
分析：
Q apply程序检查从Q Capture程序发送过来的消息，这些消息都具有一个依次递增的号码，递增增幅为1。当Q apply发现消息之间的号码不是依次递增时，Apply程序将停止处理并且将相关信息写入apply log中。可以通过命令"db2 ? ASN7551E"来获取更多信息。下面即是截取的一部分：
用户响应（ASN7551E）:
在用来在 Q Capture 和 Q Apply 程序之间传输消息的所有WebSphere MQ 队列管理器的所有"死信队列"上查找具有期望消息标识的消息。如果恢复消息，则将它放置在接收队列上，并保留WebSphere MQ 消息头信息（尤其是消息标识）。如果不能恢复消息，则遵循下列步骤：
1. 使用 stopq 命令来停止 Q Apply 程序从接收队列中进行读取。
2. 取消**此复制队列图的所有 Q 预订。
3. 清空发送队列和接收队列。
4. 使用 startq 命令，以便 Q Apply 程序继续从接收队列中进行读取。
5. **此复制队列图的所有 Q 预订。
解决：
通过如下步骤，可以解决这个问题：
1. asnqacmd apply_server=ITAGGET apply_schema=ASN stoptq=WEST_TO_EAST_Q
2. 在RC中将该Q subscriptions设置成为"deactivate"的状态。
3. 通过RC将WEST_TO_EAST_Q清空。
4. asnqacmd apply_server=ITARGET apply_schema=ASN startq=WEST_TO_EAST_Q
5. 再次将Q subscriptions设置成为"active"的状态。
对于该错误一个较好的方法就是：在启动Q Capture或者Q Apply之前，将QM_EAST和QM_WEST 上的admin、restart、和send_receive queueus 清空。
问题3描述：
2005-10-16 15:48:16.171000 ERROR ASN0005E CAPTURE "ASN" : "WorkerThread". The Capture program encountered an error when reading the DB2 log. The log sequence number is "0000:0000:0000:0697:A8BD", the SQLCODE is "-2650", and the reason code is "piStartLSNdb2ReadLog2".
分析：
这个错误主要可能是由于DB2的内部错误引起的。
解决：
完全重新安装DB2来解决这个问题。
问题4描述：
2005-10-16-19.40.47.328000 <dbConnection::dbConnectCtx> ASN0552E "Q Apply" : "ASN" : "BR00000SP001" : The program encountered an SQL error. The server name is "SAMPLE". The SQL request is "CONNECT". The table name is "N/A". The SQLCODE is "-30082". The SQLSTATE is "08001". The SQLERRMC is "3PASSWORD MISSING". The SQLERRP is "SQLEXSMC".
分析：
这个错误主要是由于缺少password文件而导致的。
解决：
安装本文上述相关内容生成password文件即可。