DB2 遠程 Q 複製實踐-以及實操過程故障排除記錄

出錯分析及解決

問題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數據庫系統的代碼頁：

可以通過如下簡單的命令來核對上述修改是否成功：

如果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上運行如下命令：

如果沒有錯誤信息顯示，表明該channel成功運行。之後打開另外一個命令行窗口，並輸入如下的命令：

如果此時返回相關錯誤碼，那麼對其進行分析並根據錯誤提示去採取相應的解決辦法。

(2). 測試本地的queues 在EAST上，執行如下命令將一個消息放到隊列上：

然後通過執行下面的命令來從queue中獲取信息。這個時候應該會顯示出上面輸入的消息文本。

在WEST端，執行如下命令來將一個消息放到隊列裏面：

同樣的，執行如下命令來從queue中獲取信息。這個時候應該也會顯示出上面輸入的相關消息文本。

(3). 測試遠程的queues 測試從遠端的queue上面放入和取出消息。

在EAST上執行如下命令來將消息放入到WEST_ADMINQ這個隊列中。

在WEST中執行如下命令獲取來自WEST_ADMINQ 隊列上的消息。

步驟註解

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)端通過如下命令來實現其轉換：

第三部分
通過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複製的相關操作，以及一些相關的核心概念。對於操作過程中常見的問題和錯誤進行了分析並給出了一般的解決方法。

以下文章點擊率最高