如何進行WebShpere MQ 運行故障的定位分析和排除(三)

消息序列號是保證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來分析故障原因。

 

 

 

以下文章點擊率最高

Loading…

     

如果這文章對你有幫助,請掃左上角微信支付-支付寶,給於打賞,以助博客運營

發表評論

您的電子郵箱地址不會被公開。 必填項已用*標註