如何进行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提供的错误日志之前已经作过较为详细的介绍,错误日志是出现异常情况时,系统管理员查找原因时要最先考虑也最为简洁奏效的办法。通道错误日志中的错误信息,往往能很快解决问题。
通常从以上几方面考虑,通道问题都能迎刃而解。

阅读更多

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

您需要检查一下对方的MQ是否处于运行状态以及对方的通道侦听程序是否启动;如果错误日志显示”通道未在远程定义”,您可以检查您定义的通道的大小写是否正确等。

2 常见故障分析

在开始详细分析问题的原因之前,我们应该首要考虑一下可能导致问题的一些较明显的因素,或导致问题发生的最大可能性因素,这样便于把分析问题的范围限制到最小。

如前所述,有关的MQ的异常情况的发生,通常主要与三方面的因素有关,即:

MQSeries本身

网络

客户的应用

2.1 初步分析

当出现问题时,可从这三方面着手分析原因,这里,列举了一些基本问题,您可以按照此顺序来查找问题的原因。

  • 在此之前MQ是否运行正常?
  • 从最近一次成功运行以来,是否在某些地方作过改动?
  • 在此之前,应用是否运行成功?
    如果您的系统曾经运行正常,那麽在出现问题之前,您对哪些部分做了改动,如:有的用户可能由于网络重新规划而更改了某个主机的IP地址,则可能导致通道无法连通;有的用户新设置了防火墙,则需要进行相应的配置,才能使MQ的通道运行正常。如果您没有对系统配置做过更改,您可以分析是否运行环境发生了变化,如:是否由于业务量的加大导致应用程序队列满了,您需要加大队列的最大深度;是否由于连接数量的增加,导致无法建立新的连接,这时,您需要察看在队列管理器配置文件中,与通道相关的MaxChannels和MaxActiveChannels的配置是否足够大。
  • 有无错误信息?
    可以察看错误日志,得到错误信息。
  • 是否与MQI应用有关,利用返回码能否解释原因?
    对于每一个函数调用,MQ都会返回一个Completion Code和Reason Code,通过MQI返回码Reason Code,可以在API一层,确定错误原因,Reason Code代表的含义可以参考编程手册,或者从h头文件中获得。如:RC2035,代表没有操作权限;RC2085,表示没有该对象;RC2080,表示应用程序给出的buffer小于消息的实际大小等。
  • 问题能再现吗?
  • 从最近一次成功运行以来,是否在某些地方作过改动?
  • 在此之前,应用是否运行成功?
  • 网络是否连接正常?
  • 问题是否总在每天的某一固定时刻发生?

2.2 深入分析

如果初步分析无法解决问题,您必须更进一步查找原因,您可以近一步考虑如下问题:

2.2.1 与队列相关的问题

1) 队列状态是否正常?

  • 用DISPLAY QUEUE命令查看队列的各项状态
  • 用得到的队列信息进一步查看:
    a) 如果CURDEPTH达到MAXDEPTH,表明队列深度已满,新消息已不能再进入队列,要及时处理队列中积存的消息;或者增大队列的MAXDEPTH属性。 b) 如果CURDEPTH还没有达到MAXDEPTH,再考虑以下两种情况:
    如果队列被设置为可触发类型的,要检查触发条件有没有满足?相关触发进程的定义是否正确?如果队列不是触发类型的,要检查队列是否为可共享的,是否允许PUT或GET的操作等。

阅读更多