Question

在使用dmpmqcfg命令备份远程队列管理器时，我得到MQSC超时，等待来自命令服务器的响应。以下是我正在使用的命令。

dmpmqcfg -m <Queue Manager> -r <remote qmgr> -x all -a -o mqsc > D:\RemoteQueueManagerBackup\RemoteQmgr.txt

在运行此命令之前，我在两个队列管理器端创建了一个服务器和请求者通道，并且在执行时，上述命令通道进入运行状态但无法进行备份。

对于一些队列管理器来说，它的工作正常，而且很少有它不起作用。我检查了运行qmgr和其他两个看起来相同的所有属性。

更新

具有名称队列管理器的Xmitq队列被定义为两端，例如：队列管理器A Xmitq为B，对于队列管理器B Xmitq为A.服务器和请求者通道被创建。触发命令时，通道进入运行状态。

从dmpmqcfg返回的任何错误？ ---没有。
是否启用了DLQ并定义了指定名称的队列？ - 是的
两端DLQ上是否有消息？ - 消息存储在远程队列管理器死信队列中。
手动启动时两个QMgrs之间的通道是否运行（这可能是触发问题而不是名称解析）？ - 通道自动运行（启用触发）否
与Auth相关的错误？我们看到的唯一错误是

AMQ9544：未将消息放入目标队列。

说明：在处理频道＆＃34; x.Y＆＃34;一个或多个   消息无法放入目标队列并尝试   使他们成为一个死信队列。队列的位置是   2，其中1是本地死信队列，2是远程队列   死信队列

操作：检查DLQ的内容。每条消息都包含在   描述消息放入队列的原因的结构，以及   最初解决的问题。另请查看以前的错误   消息，以查看是否尝试将消息放入dlq失败。该   处理程序的程序标识符（PDI）是＆＃39; 5608（10796）＆＃39;

已审核的远程死信队列原因： MQRC_PERSISTENCE_NOT_ALLOWED

Answer 1

您没有提及频道及其XMitQ的详细信息。为了使消息到达远程机器并且回复每个QMgr需要能够解析到另一个的路径。这意味着某些东西必须具有远程QMgr的名称。这个东西必须是XMitQ本身或指向XMitQ的QMgr别名。

例如，您有<Queue Manager>和<remote qmgr>。本地QMgr可能有一个名为<remote qmgr>的传输队列，它可以解析该目的地。由于您没有从dmpmqcfg报告任何错误，我将假设消息已发送出去。

这意味着消息没有回来。这可能是因为远程QMgr的XMitQ的名称类似于<Queue Manager>.XMITQ而不是<Queue Manager>。这可以通过定义QMgr别名来解决：

DEF QREMOTE('<Queue Manager>') +
    XMITQ('<Queue Manager>.XMITQ') +
    RNAME(' ') +
    RQMNAME('<Queue Manager>') + 
    REPLACE

如果这确实是错误的，你应该在远程QMgr上的DLQ中看到一些消息 - 假设在QMgr属性中定义并指定了一个消息。

如果这不能解决问题，请提供其他信息，包括：

从dmpmqcfg
是否启用了DLQ并且定义了指定名称的队列
两端DLQ上是否有消息
手动启动时两个QMgrs之间的通道是否运行（这可能是触发问题而不是名称解析）
所涉及的QMgrs平台
错误日志中的任何相关条目，包括auths错误（例如，mqm在Linux上是有效ID但在Windows上不是，因此如果发送QMgr是Linux和远程，则会在此方案中生成auths错误QMgr Windows）

更新回复有问题的其他信息
所以看起来你至少有几个问题。您发现的是临时动态队列不接受持久消息。如果你仔细想想，这就完全有道理了。如果消息是持久的，这告诉MQ采取所有预防措施以防丢失它。但是，在释放最后一个输入句柄时会删除临时动态队列，并丢弃它所拥有的任何消息。

任何将持久性消息放入临时动态队列的尝试都会向MQ发送冲突信号。它是否应该接受它知道将被隐式删除的持久消息？或者它是否应该删除临时动态队列以保留消息？它不是试图猜测用户的意图，而是简单地禁止该行动。因此，您的持久回复消息到达本地QMgr，找到临时动态队列，然后转移到DLQ。

您已经找到了解决此问题的方法。好吧，无论如何，这个问题的解决方案之一 - 改变DEFPSIST，以便消息是非持久的。另一种解决方案是使用dmpmqcfg的客户端连接功能直接连接到远程QMgrs而不是通过本地QMgr进行路由。

对于剩下的几个QMgrs，您需要再次运行相同的诊断。检查错误消息，两端DLQ的深度，通道运行，验证错误。请记住，资源错误，身份验证错误，路由问题等都可能发生在任何一端，因此请在两个QMgrs上查找错误消息和错误路由消息。此外，通过向QMgrs和从两个QMgrs发送消息到SYSTEM.DEFAULT.LOCAL.QUEUE或应用程序队列等已知队列来验证通道。

玩＃34的游戏时的另一种有用的技巧，其中包括我的消息＆＃34;是在发送命令之前通过在两个方向上停止通道来跟踪消息流。然后，您可以运行dmpmqcfg并在出站XMitQ上查看深度以验证命令是否已发送。（如果您想要浏览消息，则必须GET启用XMitQ，因为通道代理GET禁用它。这将允许您验证它们的持久性，到期值等。）

假设命令看起来没问题，则只启动出站通道，让消息流到处理它们的远程QMgr。由于返回通道仍然停止，因此回复在返回XMitQ中堆叠。您可以在那里查看它们以确定其持久性，到期时间以及命令的返回代码/结果等内容。如果它们看起来没问题，请启动该频道，然后在本地QMgr上查找它们。

对于仍有问题的少数QMgrs，您应该能够轻松找到消息丢失或被丢弃的位置。请记住，非持久性消息是通过任何工作单元之外的通道发送的，因此如果没有有效的目的地（或者它们没有被授权），它们将被静默丢弃。这种在XMitQs上捕获它们的诊断方法会隔离每一步，这样如果它们被丢弃，你就可以找到它们的位置和原因。

使用dmpmqcfg进行远程队列管理器备份无效

1 个答案: