任何一種軟體，都會存在一定的系統管理工作，WebSphere MQ也不例外，在使用WebSphere MQ（以下簡稱MQ）時，我們可能會由於配置的原因或者由於系統的原因，也可能由於MQ本身的原因，而遇到MQ執行過程中的一些故障和問題，如何能夠快速地定位這些問題，分析問題發生的原因，進而快速地解決問題，恢復系統正常執行呢？這需要一定的經驗積累和技巧，本文將對這方面給出一些簡單的提示和方法。

其實，MQ的故障分析手段很多，例如MQ的錯誤日誌即是一種簡單易行、快速有效的手段，通過檢視錯誤日誌往往能一針見血地迅速解決問題，另外MQ還提供了其它一些手段，如通過作 trace 和 FFST (First Failure support technology) 等途徑，來追蹤和記錄錯誤資訊，從而解決問題。

作為一個跨平臺的中介軟體產品，MQ在各個平臺上的系統管理方法也有極大的相似之處，尤其在AIX，SUN，HP-UNIX等Unix平臺和WindowsNT/2000平臺上，本文將以MQ for Windows NT/2000 為例，幫助您分析和定位產品執行過程中可能發生的問題，並給出查詢問題的辦法，幫助您分析問題產生的可能原因，從而給出解決問題的途徑。

在分析故障原因時，通常可從一個或一系列症狀入手，對它們進行跟蹤以發現問題發生的原因。然而，診斷問題不是解決問題。但是，問題診斷的過程常使你能夠解決問題。例如，如果你發現引起問題的原因是應用程式中的一個錯誤，你就可以通過改正該錯誤來解決問題。如果在確定了問題的原因並採取了相應措施後，您仍不能解決問題，您可以和IBM支援中心聯絡以幫助您解決問題。

MQ作為一個通訊中介軟體產品，它的執行故障概括而言主要與網路、MQ本身以及客戶應用三個方面有關，通常出現故障時，主要要從這三方面考慮，當然還需要排除和考慮其它一些額外因素，例如，是否別的應用出現異常，把記憶體等資源耗盡從而導致了MQ的執行失敗等等。

MQ為我們提供了豐富的故障分析手段，例如，MQ的系統管理命令，MQ的各種型別的錯誤日誌，MQ的trace, FFST等。以下本篇將從錯誤日誌、常見故障分析等幾方面探討一下MQ的故障分析技巧。首先我們討論對於發現問題、解決問題十分重要，也非常奏效的MQ提供的錯誤日誌手段，然後討論在MQ執行過程中可能會出現的問題，並給出基本的解決方案，最後簡單討論MQ提供的trace和 FFST(First Failure support technology) 兩種錯誤分析手段。

1 錯誤日誌分析

當MQ執行過程中，出現問題時，我們第一個應該採取的行動應該是察看MQ的錯誤日誌。注意，在這裡，不要將MQ系統的資料日誌和錯誤日誌相混淆。MQ的資料日誌包含了"data"和"action"兩部分，在NT/2000平臺上位於/mqm/log下（假設MQSeries產品安裝目錄為C:\MQM下），是對MQ的訊息資料以及使用者對MQ的操作的紀錄，是用於資料備份和系統恢復時使用的，也是資料不丟失、不重複的保障。而MQ的錯誤日誌是對MQ系統執行過程中出現錯誤的紀錄，它是我們查詢錯誤原因的最簡單快捷，最方便有效的手段。使用者一定要掌握這一方法，養成察看錯誤日誌的良好習慣。

MQ在各種層次上，為使用者提供了豐富的日誌檔案，這些日誌檔案包含了所有被啟動的佇列管理器、有關對MQ的佇列管理器操作、以及被啟動的通道的相關資訊，當佇列管理器和通道等執行時，有關資訊包括出現異常情況時的資訊都將在日誌檔案中有所體現。

在Windows NT/2000環境中，各個日誌檔案的位置如下(假設MQSeries產品安裝目錄為C:\MQM下)：

若佇列管理器名稱已知，並且處於執行狀態，錯誤日誌位於：

c:\mqm\qmgr\QMgrName\errors

若佇列管理器不處於執行狀態，則錯誤日誌位於：

c:\mqm\qmgrs\@SYSTEM\errors

若錯誤與系統有關，則錯誤日誌位於：

c:\mqm\errors

若錯誤與MQ客戶端程式有關，則錯誤日誌位於客戶機的根目錄下：

c:\mqm\errors

另外，對於MQ for Windows NT/2000平臺, 錯誤資訊也會被加在作業系統的Application Log中，通過NT/2000作業系統提供的事件日誌也可以檢測和察看到。

1.1 日誌檔案

在MQ產品安裝時，在qmgrs路徑下會建立@SYSTEM的子目錄，在errors子目錄下會產生三個日誌檔案：

   AMQERR01.LOG
   AMQERR02.LOG
   AMQERR03.LOG

當你建立了佇列管理器以後，該佇列管理器所需的日誌檔案隨之產生。在mqm\qmgr\QMgrName\errors子目錄下會產生三個日誌檔案：

   AMQERR01.LOG
   AMQERR02.LOG
   AMQERR03.LOG
   每個檔案的大小為：256KB。

當錯誤資訊產生後，被放在AMQERR01.LOG中。當AMQERR01.LOG大於256KB時，AMQERR01.LOG中的資訊被拷貝到AMQERR02.LOG中，新的錯誤資訊又放在AMQERR01.LOG檔案中，依此類推。

因此，最新的錯誤資訊總是儲存在AMQERR01.LOG中，歷史資訊儲存在AMQERR02.LOG 和 AMQERR03.LOG中。我們應該按照該順序察看錯誤資訊，並從該檔案中獲取資訊，根據它的提示採取相應的措施，例如：如果TCP/IP出錯，您需要檢查一下網路狀態是否正常；如果發現無法連線對方的佇列管理器，您需要檢查一下對方的MQ是否處於執行狀態以及對方的通道偵聽程式是否啟動；如果錯誤日誌顯示"通道未在遠端定義"，您可以檢查您定義的通道的大小寫是否正確等。

回頁首

2 常見故障分析

在開始詳細分析問題的原因之前，我們應該首要考慮一下可能導致問題的一些較明顯的因素，或導致問題發生的最大可能性因素，這樣便於把分析問題的範圍限制到最小。

如前所述，有關的MQ的異常情況的發生，通常主要與三方面的因素有關，即：

  MQSeries本身
  網路
  客戶的應用

2.1 初步分析

當出現問題時，可從這三方面著手分析原因，這裡，列舉了一些基本問題，您可以按照此順序來查詢問題的原因。

• 在此之前MQ是否執行正常？
• 從最近一次成功執行以來，是否在某些地方作過改動？
• 在此之前，應用是否執行成功？ 
  如果您的系統曾經執行正常，那麼在出現問題之前，您對哪些部分做了改動，如：有的使用者可能由於網路重新規劃而更改了某個主機的IP地址，則可能導致通道無法連通；有的使用者新設定了防火牆，則需要進行相應的配置，才能使MQ的通道執行正常。如果您沒有對系統配置做過更改，您可以分析是否執行環境發生了變化，如：是否由於業務量的加大導致應用程式佇列滿了，您需要加大佇列的最大深度；是否由於連線數量的增加，導致無法建立新的連線，這時，您需要察看在佇列管理器配置檔案中，與通道相關的MaxChannels和MaxActiveChannels的配置是否足夠大。
• 有無錯誤資訊？ 
  可以察看錯誤日誌，得到錯誤資訊。
• 是否與MQI應用有關，利用返回碼能否解釋原因？ 
  對於每一個函式呼叫，MQ都會返回一個Completion Code和Reason Code，通過MQI返回碼Reason Code，可以在API一層，確定錯誤原因，Reason Code代表的含義可以參考程式設計手冊，或者從cmqc.h標頭檔案中獲得。如：RC2035，代表沒有操作許可權；RC2085，表示沒有該物件；RC2080，表示應用程式給出的buffer小於訊息的實際大小等。
• 問題能再現嗎？
• 從最近一次成功執行以來，是否在某些地方作過改動？
• 在此之前，應用是否執行成功？
• 網路是否連線正常？
• 問題是否總在每天的某一固定時刻發生？

2.2 深入分析

如果初步分析無法解決問題，您必須更進一步查詢原因，您可以近一步考慮如下問題：

2.2.1 與佇列相關的問題

1) 佇列狀態是否正常？

• 用DISPLAY QUEUE命令檢視佇列的各項狀態
• 用得到的佇列資訊進一步檢視： 
  a) 如果CURDEPTH達到MAXDEPTH，表明佇列深度已滿，新訊息已不能再進入佇列，要及時處理佇列中積存的訊息；或者增大佇列的MAXDEPTH屬性。 b) 如果CURDEPTH還沒有達到MAXDEPTH，再考慮以下兩種情況： 
  如果佇列被設定為可觸發型別的，要檢查觸發條件有沒有滿足？相關觸發程序的定義是否正確？如果佇列不是觸發型別的，要檢查佇列是否為可共享的，是否允許PUT或GET的操作等。

2) 訊息是否成功地放入佇列?

如果訊息沒有成功地放入佇列，您可以檢查：

• 佇列是否被正確定義?例如，佇列的MaxMsgLength屬性是否足夠大以容納所需大小的訊息?
• 佇列是否被允許放入?
• 佇列是否已滿?這可能意味著應用程式無法將要求的訊息放入佇列。
• 有沒有另一個應用程式取得了獨佔佇列的權力?

3) 你是否可以從佇列取出任何訊息?

如果你無法從佇列中取出任何訊息，檢查：

• 其他應用程式能否從佇列中取出訊息?
• 有沒有另一個應用程式取得了獨佔佇列的權力?

如果你正在開發應用程式，檢查：

• 你是否需要使用一個同步點? 如果使用同步點控制來放入或檢出訊息，它們直到工作單元被提交前不能用於其它任務。
• 是否等待了足夠長的時間? 作為MQGET呼叫的一個選項，你可以設定等待間隔。你應該確保等待響應足夠長的時間。
• 你是否在等待一條由訊息或相關識別符號（MsgId或CorrelId）標識的特定訊息?

檢查你在等待的訊息的MsgId或CorrelId是否正確。成功的MQGET呼叫會把這些值設定為檢索到的訊息的值，所以你可能要重設這些值以便成功地取出另一條訊息。

• 您對訊息是否進行了分段處理，您是否在利用MQGET讀取訊息時，採用了正確的選項(MQGMO)，從而獲取訊息的整體。
• 還要檢查一下你是否能夠從佇列中取出另一條訊息。
• 你期望的訊息有沒有被定義為持久的? 如果沒有，並且MQ重新啟動後，訊息將已丟失。

4）問題是否與遠端佇列有關？

如果問題是否與遠端佇列有關，則要考慮以下幾個方面：

• ￠ 遠端佇列的定義是否正確；
• 檢查通道是否啟動，如果通道是可被觸發的，要檢查觸發監視器是否執行正常；
• 檢查往遠端佇列裡傳送訊息的應用程式是否執行正常；
• 從錯誤日誌中查詢資訊；

2.2.2 與通道相關的問題

MQSeries的通道是MQ的重要組成部分，是MQ的難點和精華，它執行正常與否對MQ系統的正常執行起著致關重要的作用，並且，在MQ的網路環境中，相當數量的異常問題與通道有關，因此，相比而言，對MQ通道的維護工作是MQ系統管理員系統管理工作的重點。下面，我們給出當通道出現異常時，判斷通道狀態、分析問題原因、以及解決通道問題的途徑和基本手段。

這裡先給出有關通道的幾個基本概念：

1) 通道狀態

通道狀態有binding、running、stopping、stoped、retrying等幾種型別，當我們發出啟動通道的命令之後，通道進入binding的狀態，若網路連線暢通並且通道定義正確，它進入正常running狀態；而在異常情況下，比如網路連線有問題、通道定義不正確或通道兩端的訊息序列號(Message Sequence Number)不匹配等，通道即進入retrying的狀態，它會根據通道定義中short retry和long retry的次數和時間間隔依次進行short retry和long retry，若不成功，則通道無法正常啟動。

2) 訊息序列號(Message Sequence Number)

訊息序列號是保證MQ訊息傳輸不丟失、不復傳的一個重要機制。訊息序列號由傳送通道分配，是通道的一個永久屬性，每當傳送一條訊息，訊息序列號就加一，正常情況下，通道兩端的訊息序列號或者相等或者相差為一，通道才能正常啟動。

通道狀態異常時應採取的措施：

1) 檢視網路連線是否暢通MQ的通訊是建立在系統網路執行正常的基礎之上的，當通道不通時，要首先檢查網路連線是否正常。您可以使用作業系統ping命令，也可以採用ftp方式，在兩個主機之間嘗試進行資料傳輸，以判斷網路是否正常。

2)檢視通道定義是否正確通道所使用的傳輸佇列定義是否正確，通道兩端的定義是否匹配，如兩條通道最大傳輸的訊息長度，Message sequence number wrap是否一致。若不一致，要重新定義通道，可使用MQSC命令DEFINE CHANNEL命令。

3)檢視通道的狀態

1. 用以下命令來判斷通道狀態： 
   dis chstatus(ChannelName)或dis chs(ChannelName) 
   其中，ChannelName代表通道的名稱，該命令支援萬用字元，可用dis chs(*)來檢視所有通道的狀態，
2. 當通道無法正常啟動時，必須重新啟動通道，可使用MQ的控制命令runmqchl命令，或MQSC命令START CHANNEL來啟動通道。 
   注意：如果通道的接收方狀態處於STOPPED狀態，必須用start chl(ReceiverChl)來重置它的狀態，注意，這並不意味著啟動了通道，欲啟動通道，必須從傳送端來啟動。
3. 如果通道處於可疑(in-doubt)狀態，則通道啟動階段的互相同步工作無法完成，也會導致通道無法啟動。解決方案是：用Resolve Channel命令來確定通道狀態；Resolve Channel命令帶有兩個引數：COMMIT和BACKOUT，用COMMIT引數將傳輸佇列中的訊息刪除，用BACKOUT引數將傳輸佇列中的訊息重新恢復。

4) 檢視作業系統、MQ的TCP/IP引數是否設定成功以及runmqchi程序是否處於執行狀態 
如果您的通道在網路出現異常或對方佇列管理器重啟後，MQ通訊不能正常恢復，則您要檢查您的作業系統的keepidle的TCP/IP相關引數是否設定成功並且生效，同時您要檢查佇列管理器的屬性TCP: KeepAlive是否設定為Yes，另外，您的runmqchi程序是否處於執行狀態。 
注意：上述三者共同作用，才能保證MQ通道的正常恢復，缺一不可。

5）檢視通道的當前訊息序列號 
用dis chstatus(ChannelName)或dis chs(ChannelName)檢視通道的當前一些屬性值，在通道的屬性值中，current sequence number代表通道當前的訊息序列號值，若訊息序列號不一致，則可用MQSC命令RESET CHANNEL命令來將訊息序列號重新置1。 
注意：一般情況下，只有當某一方MQ系統重新安裝，佇列管理器重建，或人為操作時，才會使通道的訊息序列號變為1。

6) 檢視錯誤日誌 
關於MQ提供的錯誤日誌之前已經作過較為詳細的介紹，錯誤日誌是出現異常情況時，系統管理員查詢原因時要最先考慮也最為簡潔奏效的辦法。通道錯誤日誌中的錯誤資訊，往往能很快解決問題。 
通常從以上幾方面考慮，通道問題都能迎刃而解。

2.2.3 死信佇列

如果由於某種原因，訊息不能被正常傳送，它會被送到死信佇列中。你可以用MQSC目錄DISPLAY QUEUE來檢視死信佇列的深度，若佇列中有訊息，可利用應用程式瀏覽訊息的內容，來確定訊息被放入死信佇列的原因，從而確定如何處理死信中的訊息。訊息有可能出現在本地的佇列中，也有可能出現在目的地的死信佇列中。若發生前一種情況，說明本地某有正確的路由途徑，可以使訊息繼續下傳；若發生後一種情況，說明目的地一端所指定的目的佇列不存在。

2.2.4 配置檔案

對於每一個佇列管理器而言，都有一個名為qm.ini的配置檔案，如果該配置檔案被誤刪除，會導致"queue manager unavailable"型別的錯誤。在Windows NT/2000平臺上，該配置檔案以登錄檔方式存在，可以使用MQ提供的圖形介面進行修改。注意：對qm.ini和佇列管理器屬性的修改，必須在佇列管理器重新啟動之後才能生效。

2.2.5 資料日誌

前面曾經提到MQ的資料日誌，一般情況下，中國使用者大多采用迴圈日誌，我們建議您在估算訊息容量之後，確定適當的日誌大小和個數。如果，在執行過程中，出現了日誌寫滿的情況，MQ也無法正常執行，您可以採取修改qm.ini配置檔案的方法，加大日誌大小和個數。

2.3 檢視系統及應用的執行情況

若從上述兩個方面都沒有解決問題，最後您就要從系統和應用的角度去進一步分析問題了，比如，您可檢視您的系統執行速度是否正常，系統資源是否耗盡等，從而確認是否系統問題影響了MQ的正常執行。

回頁首

3 Trace

錯誤跟蹤也是一種跟蹤故障的手段，在MQ for Windows NT/2000環境中，我們可以用"strmqtrc"命令來追蹤問題的發生原因。

Trace檔案除特殊指定，一般放在\mqmwork\errors目錄下，檔案的命名規律是：AMQppppp.TRC 
(注：ppppp是產生trace的程序識別符號(PID))。

注意：啟動trace跟蹤，會影響系統的效能，所以在生產環境中要慎重使用。Trace檔案的內容，使用者是無法分析和讀懂的，要由IBM實驗室進行分析。

回頁首

4 FFST(First Failure support technology)

在WindowsNT環境中，FFST訊息檔案位於c:\mqm\errors目錄下。這些錯誤一般較為嚴重，一般表現為系統錯誤或MQ內部錯誤。

FFST檔案的命名規則為：AMQnnnnn.mm.FDC，其中

          nnnnn-報告錯誤的程序識別符號(PID)
        mm-序列號，一般為0

在FDC檔案中，對我們有幫助的是它的開始部分，我們可以參考它的ErrorCode, Probe Type, Probe Description部分的內容來分析原因。它的主要部分也是需要由IBM試驗室來分析的，IBM藉助MQM Function Stack和MQM Trace History來分析故障原因。

參考：http://www.ibm.com/developerworks/cn/websphere/library/techarticles/loulijun/MQSystemManage.html