如果问题是否与远程队列有关，则要考虑以下几个方面：
￠
远程队列的定义是否正确；
检查通道是否启动，如果通道是可被触发的，要检查触发监视器是否运行正常；
检查往远程队列里发送消息的应用程序是否运行正常；
从错误日志中查找信息；
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来分析故障原因。
以上，我们初步讨论了有关MQSeries故障分析的一些方法和技巧，希望对大家有所帮助。
以下文章点击率最高
Loading…