[AIX]

在 AIX 上确定应用程序，命令和消息的问题

如果迂到有关 IBM® MQ 应用程序，命令和消息的问题，那么可以考虑一些问题来帮助您确定问题的原因。

关于本任务

使用以下问题作为提示来帮助确定问题原因：

在核对该列表的过程中，请记下可能与问题相关的所有信息。 即使您的观察结果没有直接表明原因，但如果您需要进行系统的问题确定练习，那么这些观察结果可能会在稍后有用。

当您使用 IBM提交案例时，可以包含为帮助调查问题而收集的其他 IBM MQ 故障诊断信息 (MustGather 数据)。 更多信息，请参阅收集故障排除信息。

过程

  1. 消息是否未能到达队列？
    如果期望消息时消息未到达，请检查消息是否已成功放入队列中:
    • 队列正确定义了吗？ 例如， MAXMSGL 是否足够大?
    • 队列启用了放入吗？
    • 队列已经满了吗？
    • 另一个应用程序得到了对队列的互斥访问权了吗？
    还要检查您是否能够从队列中获取任何消息:
    • 您需要获取同步点吗？ 如果在同步点中放入或检索消息，在落实恢复单元前，它们不可用于其它任务。
    • 您的等待时间间隔足够长吗？ 您可以将等待时间间隔设置为 MQGET 调用的一个选项。 确保您等了足够长的时间以获得响应。
    • 您在等由消息或相关标识标识的特定消息吗（MsgId 或 CorrelId）？ 检查您是否在用正确的 MsgId 或 CorrelId 等待消息。 成功的 MQGET 调用将这两个值都设置为检索的消息的值，因此，您可能需要复位这些值才能成功地取出另一个消息。 同样，检查是否可以从队列取出其他消息。
    • 其他应用程序可以从队列取出消息吗？
    • 您预期的消息是定义为持久的吗？ 如果没有，并且 IBM MQ 已重新启动，那么消息已丢失。
    • 另一个应用程序得到了对队列的互斥访问权了吗？
    如果找不到队列有任何错误，并且 IBM MQ 正在运行，请检查您期望将消息放入队列中的进程，以了解以下内容:
    • 应用程序启动了吗？ 如果应该已经触发了该应用程序，请检查是否指定了正确的触发器选项。
    • 应用程序停止了吗？
    • 是否正在运行触发器监视器？
    • 正确定义了触发器进程吗？
    • 应用程序正确完成了吗？ 查找作业日志中的异常结束证据。
    • 应用程序落实其更改了吗？或将它们回退了吗？

    如果有多个事务在为此队列提供服务，它们可能会相互冲突。 例如，假设有一个事务发出缓冲区长度为零的 MQGET 调用，以查找消息的长度，然后发出指定了那个消息的 MsgId 的特定 MQGET 调用。 然而，与此同时，另一个事务为该消息发出了成功的 MQGET 调用，因此第一个应用程序收到原因码 MQRC_NO_MSG_AVAILABLE。 必须将可能要在多个服务器环境中运行的应用程序设计为能处理上述情况。

    考虑可能接收到的消息，但出于某种原因您的应用程序未能处理它。 例如，是由于所要的消息格式出错而导致程序拒绝它吗？ 如果是，请参阅本主题中的后续信息。

  2. 消息包含意外或损坏的信息吗？
    如果在消息中包含的消息不是应用程序所预期的，或已经以某种方式损坏，那么考虑以下各项：
    • 您的应用程序或将消息放在队列上的应用程序，被更改了吗？ 确保在所有需要注意更改的系统上都同步反映了全部更改。 例如，消息数据的格式可能已经被更改，无论哪种情况，都必须重新编译应用程序来使更改生效。 如果一个应用程序还没有被重新编译，那么将对其余应用程序来说显示为数据损坏。
    • 应用程序对错误队列发送了消息吗？ 检查确保应用程序正在接收的消息并非应该被发送到服务于另一个队列的应用程序。 若有必要，请将安全性定义更改为阻止未授权的应用程序将消息放入错误的队列。 如果应用程序使用别名队列，那么检查别名是否指向正确的队列。
    • 已经为该队列指定了正确的触发器信息吗？ 检查应该已经启动了应用程序；或应该启动了不同的应用程序吗？

    如果这些检查没有使您解决问题，那么为发送消息的程序和接收消息的程序检查应用程序逻辑。

  3. 使用分布式队列时是否收到意外的消息？
    如果您的应用程序使用分布式队列，考虑以下要点：
    • IBM MQ 是否已正确安装在发送系统和接收系统上，并且已正确配置为进行分布式排队?
    • 在两个系统之间的链接是可用的吗？ 检查这两个系统是否都可用，以及是否已连接到 IBM MQ。 检查两个系统之间的连接是活动的。 您可以对队列管理器 (PING QMGR) 或通道 (PING CHANNEL) 使用 MQSC 命令 PING 来验证链接是否可操作。
    • 在发送系统中设置了触发吗？
    • 您所等待的消息是从远程系统来的应答消息吗？ 检查远程系统中的触发已被激活。
    • 队列已经满了吗？ 如果是，检查消息是否已经被放入死信队列上。 死信队列头包含原因或反馈代码，解释为什么消息无法被放入目标队列中。 有关更多信息，请参阅 使用死信 (未传递的消息) 队列 和 MQDLH-死信头。
    • 在发送和接收队列管理器之间有不匹配吗？ 例如，消息长度可能超过了接收队列管理器可处理范围的长度。
    • 发送和接收通道的通道定义是兼容的吗？ 例如，序列号包中的不匹配可能停止分布式排队组件。 有关更多信息，请参阅分布式排队和集群。
    • 涉及数据转换吗？ 如果发送和接收应用程序之间的数据格式不同，那么数据转换是必需的。 如果格式被识别为内置格式之一，那么当发出 MQGET 调用时会发生自动转换。 如果数据格式不被转换所识别，那么采用数据转换出口来允许您用自己的例程执行转换。 有关更多信息，请参阅 数据转换。

    如果无法解决问题，请联系 IBM 支持人员以获取帮助。

  4. 您是否未收到来自 PCF 命令的响应?
    如果您发出了命令但没有接收到响应，请考虑以下检查：
    • 命令服务器在运行吗？ 使用 dspmqcsv 命令来检查命令服务器的状态。 如果对此命令的响应指示命令服务器未在运行，请使用 strmqcsv 命令将其启动。 如果该命令的响应表明 SYSTEM.ADMIN.COMMAND.QUEUE 不是为 MQGET 请求启用的，那么启用 MQGET 请求的队列。
    • 已将应答发送到死信队列了吗？ 死信队列头结构包含原因或反馈代码，对该问题进行了描述。 有关更多信息，请参阅 MQDLH-死信头 和 使用死信 (未传递的消息) 队列。 如果死信队列包含消息，那么可以使用提供的浏览样本应用程序 (amqsbcg) 通过 MQGET 调用来浏览消息。 样本应用程序为已命名队列管理器单步遍历已命名队列上的所有消息，为已命名队列上的所有消息显示消息描述符和消息上下文字段。
    • 消息被发送到错误日志了吗？ 有关更多信息，请参阅 AIX， Linux和 Windows 上的错误日志目录。
    • 队列启用了放入和取出操作了吗？
    • WaitInterval 够长了吗？ 如果 MQGET 调用超时，将返回完成代码 MQCC_FAILED 和原因码 MQRC_NO_MSG_AVAILABLE。 请参阅 WaitInterval (MQLONG) ，以获取有关 WaitInterval 字段以及来自 MQGET 的完成代码和原因码的信息。
    • 如果您正在使用自己的应用程序将命令放到 SYSTEM.ADMIN.COMMAND.QUEUE，是否需要获取同步点? 除非已从同步点排除请求消息，否则需要在接收回复消息前获取同步点。
    • 队列的 MAXDEPTH 和 MAXMSGL 属性设置是否足够高?
    • 您是否正确使用了 CorrelId 和 MsgId 字段？ 在应用程序中设置 MsgId 和 CorrelId 的值，以确保接收来自队列的所有消息。

    尝试停止命令服务器，然后重新启动，响应所产生的任何错误消息。 如果系统仍未响应，那么问题可能与队列管理器或整个 IBM MQ 系统有关。 首先，尝试停止个别的队列管理器来隔离失败的队列管理器。 如果此步骤未显示问题，请尝试停止并重新启动 IBM MQ，以响应错误日志中生成的任何消息。 如果在重新启动后仍发生此问题，请联系 IBM 支持人员以获取帮助。

  5. 是否只有部分队列失败?
    如果您怀疑问题仅在队列的子集发生，请检查您认为有问题的本地队列。

    使用 MQSC 命令 DISPLAY QUEUE 来显示有关每个队列的信息。 如果 CURDEPTH 位于 MAXDEPTH，那么表示未处理队列。 检查所有应用程序都是正常运行的。

    如果 CURDEPTH 不在 MAXDEPTH上，请检查以下队列属性以确保它们正确:
    • 如果正在使用触发，那么触发器监视器是否正在运行? 触发器深度太深吗？ 即，它通常生成足够的触发器事件吗？ 进程名正确吗？ 进程是可用的和可操作的吗？
    • 队列可以共享吗？ 如果不可以，那么另一个应用程序可能已经为输入打开了该队列。
    • 队列相应地启用了 GET 和 PUT 吗？

    如果没有应用程序进程从队列处理取出消息，那么确定为什么会这样。 这可能是因为需要启动应用程序，连接已中断，或者 MQOPEN 调用由于某种原因而失败。 检查队列属性 IPPROCS 和 OPPROCS。 这些属性表明是否已经为输入和输出打开了队列。 如果值是零，那么表明不会发生该类型的操作。 值可能已更改，或者队列可能已打开但现在已关闭。

    检查您期望放入或获取消息时的状态。

    如果无法解决问题，请联系 IBM 支持人员以获取帮助。

  6. 问题是否仅影响远程队列？
    如果问题仅影响远程队列，请执行以下检查：
    • 检查是否已经启动了必需的通道，并且可以触发该通道，以及运行必需的启动程序。
    • 检查应该将消息放入远程队列的程序没有报告问题。
    • 如果您使用触发来启动分布式排队进程，应检查传输队列是否已将触发设置为打开。 还应检查触发器监视器是否正在运行。
    • 检查错误日志，查找表明通道错误或问题的消息。
    • 若有必要，手动启动通道。
  7. 应用程序或系统运行缓慢吗？
    如果您的应用程序运行缓慢，那么可能表明它在循环中，或在等待不可用的资源，或可能存在性能问题。

    可能您的系统操作已接近容量极限了。 这类问题可能在系统负载的峰值时间最严重，通常在上午的中间时段和下午的中间时段。 （如果网络跨越了多个时区，那么系统负载峰值可能会看似发生在其他时间。）

    性能问题可能由硬件限制引起。

    如果您发现性能降低与系统负载无关，而是在系统负载较轻时发生的，那么可能要归咎于设计不良的应用程序。 只有在访问某些队列时才会出现这种问题。

    导致应用程序性能下降或在队列 (通常是传输队列) 上构建消息的常见原因是一个或多个应用程序在工作单元外部写入持久消息。 有关更多信息，请参阅 消息持久性。

    如果性能问题仍然存在，那么问题可能在于 IBM MQ 本身。 如果您怀疑这样做，请联系 IBM 支持人员以获取帮助。