爱华网任何一种软件，都会存在一定的系统管理工作，WebSphere MQ也不例外，在使用WebSphere MQ（以下简称MQ）时，我们可能会由于配置的原因或者由于系统的原因，也可能由于MQ身的原因，而遇到MQ运行过程中的一些故障和问题，如何能够快速地定位这些问题，分析问题发生的原因，进而快速地解决问题，恢复系统正常运行呢？这需要一定的经验积累和技巧，本文将对这方面给出一些简单的提示和方法。
其实，MQ的故障分析手段很多，例如MQ的错误日志即是一种简单易行、快速有效的手段，通过查看错误日志往往能一针见血地迅速解决问题，另外MQ还提供了其它一些手段，如通过作 trace 和 FFST (First Failure support technology) 等途径，来追踪和记录错误信息，从而解决问题。
作为一个跨平台的中间件产品，MQ在各个平台上的系统管理方法也有极大的相似之处，尤其在AIX，SUN，HP-UNIX等Unix平台和WindowsNT/2000平台上，本文将以MQfor 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:mqmqmgrQMgrNameerrors
若队列管理器不处于运行状态，则错误日志位于：
c:mqmqmgrs@SYSTEMerrors
若错误与系统有关，则错误日志位于：
c:mqmerrors
若错误与MQ客户端程序有关，则错误日志位于客户机的根目录下：
c:mqmerrors
另外，对于MQ for Windows NT/2000平台, 错误信息也会被加在操作系统的Application Log中，通过NT/2000操作系统提供的事件日志也可以检测和察看到。
1.1 日志文件
在MQ产品安装时，在qmgrs路径下会建立@SYSTEM的子目录，在errors子目录下会产生三个日志文件：
AMQERR01.LOG
AMQERR02.LOG
AMQERR03.LOG
当你建立了队列管理器以后，该队列管理器所需的日志文件随之产生。在mqmqmgrQMgrNameerrors子目录下会产生三个日志文件：
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）问题是否与远程队列有关？
如果问题是否与远程队列有关，则要考虑以下几个方面：
￠ 远程队列的定义是否正确；
检查通道是否启动，如果通道是可被触发的，要检查触发监视器是否运行正常；
检查往远程队列里发送消息的应用程序是否运行正常；
从错误日志中查找信息；
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) 查看通道的状态
用以下命令来判断通道状态：
dis chstatus(ChannelName)或dis chs(ChannelName)
其中，ChannelName代表通道的名称，该命令支持通配符，可用dis chs(*)来查看所有通道的状态，
当通道无法正常启动时，必须重新启动通道，可使用MQ的控制命令runmqchl命令，或MQSC命令START CHANNEL来启动通道。
注意：如果通道的接收方状态处于STOPPED状态，必须用start chl(ReceiverChl)来重置它的状态，注意，这并不意味着启动了通道，欲启动通道，必须从发送端来启动。
如果通道处于可疑(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文件除特殊指定，一般放在mqmworkerrors目录下，文件的命名规律是：AMQppppp.TRC
(注：ppppp是产生trace的进程标识符(PID))。
注意：启动trace跟踪，会影响系统的性能，所以在生产环境中要慎重使用。Trace文件的内容，用户是无法分析和读懂的，要由IBM实验室进行分析。
4 FFST(First Failure support technology)
在WindowsNT环境中，FFST消息文件位于c:mqmerrors目录下。这些错误一般较为严重，一般表现为系统错误或MQ内部错误。
FFST文件的命名规则为：AMQnnnnn.mm.FDC，其中
nnnnn-报告错误的进程标识符(PID)
mm-序列号，一般为0
在FDC文件中，对我们有帮助的是它的开始部分，我们可以参考它的ErrorCode, Probe Type, Probe Description部分的内容来分析原因。它的主要部分也是需要由IBM试验室来分析的，IBM借助MQM Function Stack和MQM Trace History来分析故障原因。
以上，我们初步讨论了有关MQSeries故障分析的一些方法和技巧，希望对大家有所帮助。
