Sql server Service Broker疑难解答：启动器数据库在转换时卡住/已通知

我们正在开发一个应用程序，它将使用ServiceBroker将消息从一个数据库传输到另一个数据库SourceDB由现有应用程序使用，我们正在从中提取一些数据TargetDB仅由此应用程序使用，并处理/分发我们需要的数据。我们只使用一种类型的契约，并且两个数据库都在同一台服务器上

我们在这两个队列上以及各自的启动器和目标队列/服务上设置了相同的消息类型和契约。在两个数据库上：

• 启用代理

  已设置

• 可信

  已设置
• 拥有唯一的

  服务\u代理\u guid

• 将

  sa

  作为db所有者，所有SSB授权声明都是

  dbo

  或

  owner

  ，视情况而定

但是，当我们从SourceDB发送消息时：

BEGIN DIALOG CONVERSATION @dialogHandle
    FROM SERVICE [//Service/Initiator]
    TO SERVICE N'//Service/Target'
    ON CONTRACT [//Contract/Notification]
    WITH ENCRYPTION = OFF;
SEND ON CONVERSATION @dialogHandle
    MESSAGE TYPE [//Message/Notification] (@RequestMsg);

……信息无法到达目的地。进一步调查显示：

D  29912 dbtestsvr  SourceDB  Service //Service/Target was not found
D  29975 dbtestsvr  SourceDB  User dbo does not have SEND permission on service //Service/Target

• 启动器队列为空
• 目标队列为空（注意：这不是需要接收的问题）
• 传输队列为空
• SQL Server日志或创建消息的存储过程中的捕获错误处理中均未记录任何错误
• 如果启用激活，SourceDB的

  sys.dm\u broker\u queue\u monitors

  中启动器队列的条目将设置为NOTIFIED
• SourceDB的

  sys.conversation\u端点

  在

  转换

  状态中有一个新条目
• 如果启用激活，TargetDB的

  sys.dm_broker_queue_监视器中的目标队列条目将保持非活动状态

• TargetDB的

  sys.conversation\u endpoints

  在

  CONVERSING

  状态中有一个新条目，与SourceDB条目具有相同的会话id和不同的会话句柄

尽管测试数据库是SQL 2005（应用程序必须支持2005），但我从我的开发机器的2008安装中运行了ssbdiagnose实用程序，以解决以下问题：

ssbdiagnose-S testserver-d SourceDB配置从服务//服务/启动器到服务//服务/合同目标//合同/通知

这产生了以下结果：

D  29912 dbtestsvr  SourceDB  Service //Service/Target was not found
D  29975 dbtestsvr  SourceDB  User dbo does not have SEND permission on service //Service/Target

这是令人困惑的，因为不应拒绝任何权限

dbo

，而且

//Service/Target

确实存在，尽管存在于不同的数据库中。但我的同事运行了一个探查器跟踪，显示正在执行一个命令，查找SourceDB上的

//Service/Target

。服务代理似乎不知怎么搞糊涂了。添加一条明确的路线，除了在理论上是不必要的之外，不会改变这种情况

我在我们的测试服务器上运行了一组几乎相同的，并且一切正常，所以它可能是特定于db的

---

我们的设置在两天前开始工作，因此我们可能正在寻找一些可能已更改但运气不佳的设置。

您正在这样做吗？：@RemusRusanu，谢谢您的回复。即使确保我们没有运行任何

END CONVERSATION

语句，这种情况仍在发生。有一件事让我很清楚：SourceDB中的dbo对目标服务没有发送权限。谁是dbo SourceDB，该用户是否需要/拥有TargetDB中的PERM？我有点失望，SB仍然是一门神秘的艺术，而且还没有做更多的工作来让它变得更简单…@BenThul，sa是SourceDB和TargetDB的db所有者。绝对感受到你对SSB降级为arcana的评论的真实性。：）我的怀疑是：1）您有多个

//Service/Target

服务副本（在多个数据库中），SSB从您期望的副本中选择了一个不同的副本；2）您有一个

//Service/Target

的路由，该路由将消息发送到未预料到的某个地方。您这样做了吗？：@RemusRusanu，谢谢您的回复。即使确保我们没有运行任何

END CONVERSATION

语句，这种情况仍在发生。有一件事让我很清楚：SourceDB中的dbo对目标服务没有发送权限。谁是dbo SourceDB，该用户是否需要/拥有TargetDB中的PERM？我有点失望，SB仍然是一门神秘的艺术，而且还没有做更多的工作来让它变得更简单…@BenThul，sa是SourceDB和TargetDB的db所有者。绝对感受到你对SSB降级为arcana的评论的真实性。：）我的怀疑是：1）您有多个

//Service/Target

服务副本（在多个数据库中），SSB从您期望的副本中选择了一个不同的副本；2）您有一个

//Service/Target

的路由，它将消息发送到意外的地方