查询通知错误答案

【问题标题】：Query Notification Error查询通知错误
【发布时间】：2009-06-19 15:05:18
【问题描述】：

我们有一个关于 SQL 查询通知服务的奇怪问题。我们有一个使用 QN 服务运行的主 Web 应用程序，因此当监控数据发生更改时，Web 中的缓存项会从 SQL 获得通知。它运行良好。奇怪的是，当其他支持的 Web 服务尝试将 QN 订阅注册到 SQL 2005 SP2 并发生此错误时

“系统异常：SqlDependency.Start 已为服务器多次调用命令正在执行的服务器，但当前命令没有匹配的服务器/用户/数据库 Start() 调用”

此错误仅在 SQLDependency 中针对特定实例 DB 进行 SQL 查询时发生。另一个实例数据库工作得很好。

对于 QN / 服务代理问题，找不到太多资源。希望有类似经历的朋友可以分享一下知识。

【问题讨论】：

这个问题已经解决，这是由于我们的全局代码中的一个错误，它没有执行 SQLDepenedency.start() 在 SQL 中的所有实例。但是，如果没有启动 SQLDependency，错误应该类似于“当使用 SqlDependency 而不提供选项值时，必须为每个正在执行的服务器调用 SqlDependency.Start()”。所以我仍然想知道为什么 SQL 会产生这个奇怪的错误。

标签： asp.net sql-server caching service-broker

【解决方案1】：

这是那些没有太多知识专家可用的 SQL Server 主题领域之一，包括我敢说，我自己 ;-)

我的建议是在 MSDN 上的官方 SQL Server Service Broker 论坛上发布您的查询。以下链接供参考：

http://social.msdn.microsoft.com/Forums/en-US/sqlservicebroker/threads

【讨论】：

【解决方案2】：

这意味着已经为此 DB 调用了 Start() 方法。 start 方法有限制，你可以在底部看到here。

【讨论】：

【解决方案3】：

这不是直接回答这个话题，而是关于QN/SSB资源的问题，我的网站上有几篇文章：

我曾是 SQL Server 团队的开发人员，我参与过 Service Broker 以及或多或少的内部使用，如查询通知和 SqlDependency、事件通知、dbMail 等。

【讨论】：

感谢您的信息，我们知道 QN 订阅需要 SQL 的资源，您能告诉我们多少 QN 订阅对于企业级 SQL 2005 服务器来说太多了吗？我们在我们的应用程序中实现了 QN，测试正常，但在生产服务器中存在性能问题。上次我检查时，他们在 SQL 中有大约 3000 个 QN 订阅。我想知道这是否是一个问题。谢谢！
3000 个 QN 模板、QN 订阅查询或 3000 个应用域订阅？每个订阅 SqlDependency 的 appdomain 在服务器上发布一个 WAITFOR RECEIVE 来阻塞线程。您必须将“最大工作线程”配置为更高的值，将所有预期的客户端应用程序域添加到“正常”值。每个查询模板都会创建一个虚假的仅元数据索引视图来通知更改，从而影响 INSERT/UPDATE/DELETE 计划。而且每个订阅的查询都需要一点状态（内存、磁盘）。
真正的杀手正在触发通知，这会占用资源（发送通知消息，接收它 = 1 次插入，3 次更新和 1 次删除（发送）+ 1 次删除（接收）。如果你每分钟触发 3000 个 QN，这对于您的 IO 来说每秒额外执行 300 个 DML 操作。这不包括重新订阅的成本。
感谢您的快速回复。 3000 个 QN 订阅查询来自 select * from sys.dm_qn_subscriptions。基本上它是一个网络农场，3 个网络服务器共享同一个 SQL 服务器。所以每个 Web 应用都有 1000 个 QN 订阅。每个 QN 订阅都用于不同的查找表，因此除非应用程序池回收，否则它不会每分钟都启动。事实上，这些数据是相当静态的。我们在 SQL Profile 跟踪中看到了很多“WAITFOR..”，因此我们将 QN 视为性能问题的嫌疑人。但我们找不到确凿的证据来证明这一点。谢谢。
哦顺便说一句，SqlDependency 发布的 WAITFOR RECEIVE 也会在 1 分钟内自行超时，所以每个 appdomain 都会在 1 分钟内重新发出 WAITFOR RECEIVE。有多少个应用程序域？（IIS 中的应用程序池）