如何进行WebShpere MQ 运行故障的定位分析和排除2

如果问题是否与远程队列有关,则要考虑以下几个方面:

    
远程队列的定义是否正确;

    检查通道是否启动,如果通道是可被触发的,要检查触发监视器是否运行正常;

    检查往远程队列里发送消息的应用程序是否运行正常;

    从错误日志中查找信息;

2.2.2 与通道相关的问题

MQSeries的通道是MQ的重要组成部分,是MQ的难点和精华,它运行正常与否对MQ系统的正常运行起着致关重要的作用,并且,在MQ的网络环境中,相当数量的异常问题与通道有关,因此,相比而言,对MQ通道的维护工作是MQ系统管理员系统管理工作的重点。下面,我们给出当通道出现异常时,判断通道状态、分析问题原因、以及解决通道问题的途径和基本手段。

这里先给出有关通道的几个基本概念:

1) 通道状态

通道状态有bindingrunningstoppingstopedretrying等几种类型,当我们发出启动通道的命令之后,通道进入binding的状态,若网络连接畅通并且通道定义正确,它进入正常running状态;而在异常情况下,比如网络连接有问题、通道定义不正确或通道两端的消息序列号(Message Sequence Number)不匹配等,通道即进入retrying的状态,它会根据通道定义中short retrylong retry的次数和时间间隔依次进行short retrylong 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命令带有两个参数:COMMITBACKOUT,用COMMIT参数将传输队列中的消息删除,用BACKOUT参数将传输队列中的消息重新恢复。

4) 查看操作系统、MQTCP/IP参数是否设置成功以及runmqchi进程是否处于运行状态

如果您的通道在网络出现异常或对方队列管理器重启后,MQ通讯不能正常恢复,则您要检查您的操作系统的keepidleTCP/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 StackMQM Trace History来分析故障原因。

以上,我们初步讨论了有关MQSeries故障分析的一些方法和技巧,希望对大家有所帮助。

以下文章点击率最高

Loading…


发表评论

电子邮件地址不会被公开。 必填项已用*标注