空間站

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數據庫可兼容，那么該命令可以成功返回。

第二部分 配置MQ對象

操作步驟

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: 通道程序異常終止。

分析：

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 "piStartLSNdb2ReadLog2".

分析：

這個錯誤主要可能是由于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 "3PASSWORD MISSING". The SQLERRP is "SQLEXSMC".

分析：

這個錯誤主要是由于缺少password文件而導致的。

解決：

安裝本文上述相關內容生成password文件即可。

結束語

本文主要介紹了遠程Q復制的相關操作，以及一些相關的核心概念。對于操作過程中常見的問題和錯誤進行了分析并給出了一般的解決方法。

下載