如何進行WebShpere MQ 運行故障的定位分析和排除如何進行WebShpere MQ 運行故障的定位分析和排除如何進行WebShpere MQ 運行故障的定位分析和排除
任何一種軟體，都會存在一定的系統管理工作，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）問題是否與遠程隊列有關？
以下文章點擊率最高
Loading…