如何进行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…


发表评论

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