Question

在较高的层面，这是正在发生的事情：

我们有两个SQL Server 2008 R2 SP1系统（Windows NT 6.1上的标准版（Build 7601：Service Pack 1））他们正在哼唱，双向沟通，没有任何错误或问题。
我们重新引导系统＃2，期望在它不可用时发送给它的任何Service Broker消息将在系统＃1上排队，直到系统＃2重新启动。
系统＃2重新启动，一切正常启动，没有错误。
系统＃1排队等待系统＃2的消息仍然排队等待;它们永远不会被发送。此外，该对话的新消息也会排队，永远不会发送。
新会话上发送的消息传输得很好。

有关永不发送的消息的详细信息：

一个。当系统＃2关闭时，队列中消息的transmission_status显示各种错误，表明它无法按预期与系统＃2通信。

B中。系统＃2恢复后不久，这些消息的transmit_status变为空白。在此之后，空白状态永远不会改变。

℃。消息堆叠的对话处于CONVERSING / CO状态。系统视图中没有列表示与其他正常工作的队列有任何不同。（如果我能找到任何不同的标志，我会知道终止糟糕的会话，但系统没有提供任何线索 - 除了不断增长的队列深度。）

d。从未在系统＃2上收到消息，因为从不为这些消息调用我的激活存储过程。

电子。在Profiler中（打开了所有Broker跟踪类型），一个好的对话会显示这些内容被记录：

Broker:Conversation CONVERSING  1 - SEND Message        Initiator                                       
Broker:Message Classify 2 - Remote  Initiator
[SQL Batch complete; SQL that caused the SEND to occur]
Broker:Remote Message Acknowledgement   1 - Message with Acknowledgement Sent   Initiator
Broker:Message Classify     1 - Local   Initiator
Broker:Conversation CONVERSING  6 - Received Sequenced Message  Target
Broker:Remote Message Acknowledgement   3 - Message with Acknowledgement Received       Initiator
Broker:Activation       Microsoft SQL Server Service Broker Activation  1 - Start

正在发送的邮件将被锁定，只显示前两个事件：

Broker:Conversation CONVERSING  1 - SEND Message    Initiator
Broker:Message Classify 2 - Remote  Initiator

据我所知，这些消息得到的距离越远。没有迹象表明SQL Server会再次尝试传输它们。系统＃1认为对话仍然很好，但系统＃2完全忘记了它。系统＃1似乎永远不会想到这一点。如果我们随后重启系统＃1，那么一切都恢复正常，所有的消息都按预期流动。

我认为这些消息实际上已经发送过，但是确认并没有将它发回系统＃1。但我没有看到任何支持队列确认的证据。

我们检查了双方的许多典型问题：

双方都启用了经纪人。 2.所有队列都已启用，所有适当的事情都已启用（入队，接收）。队列没有中毒。 3.我们不知道存在任何权限问题。我们没有使用“即发即忘”。我们正在重复谈话，正如各种人推荐的那样。（事实上，对话重用是这里的问题！） 6.我们正在捕获SQL异常，按照指示使用事务等。 7. ssbdiagnose没有返回任何错误。

重新启动SQL Server主机时，我们希望最终会发送任何排队的消息，但事实并非如此。这是怎么回事？

Answer 1

我知道这是一个非常古老的线程，但我之前已经完全相同的情况，在我的情况下，网络配置是罪魁祸首。

由于某种原因，发起人已从一个IP地址发送了其消息，但已打开另一个IP来接受传入的回复（并且已在目标路由中指定了第二个IP）。

我偶然发现了这个，真的。当我尝试在目标端结束对话时，它尚未关闭，但EndDialog消息出现在sys.transmission_queue状态：

连接尝试失败，错误：'10060（连接尝试失败，因为关联方在a之后没有正确回应一段时间，或建立的连接失败，因为连接主持人没有回复。）'。

我不知道为什么目标重启已经触发故障，但是当网络工程师修复了问题而我改变了目标的路线时，一切都从一开始就飞到了目的地。

如果目标重新启动，则不会发送Service Broker消息

1 个答案: