SQL Server Service Broker 服务消失（自动删除）？
我已经通过 SQL Server Service Broker 实现了一个消息系统。它工作得很好，唯一的例外是每隔一段时间（也许每台服务器每周一次）我的启动器服务就会消失得无影无踪。对应的队列还在，但是服务缺失了。
显然这会导致我的系统出现问题。手动重新创建服务是一件简单的事情，但我对可能导致这种行为的原因感到困惑。我知道自动有害消息处理会导致队列被禁用，但我没有看到任何表明服务可以自动禁用或删除的信息。
发生这种情况时，我通常会在多个应用程序队列中积压大量消息，但没有什么极端的情况。消息积压总量约为 200,000 条。
有谁知道这里可能发生什么？
I've implemented a messaging system over SQL Server Service Broker. It is working great, with the sole exception that every once in a while (maybe once per week per server) my initiator service just vanishes without a trace. The corresponding queue is still there, but the service is missing.
Obviously this causes problems in my system. It's a simple matter to recreate the service by hand, but I'm confused as to what might cause this behavior. I understand that automatic poison message handling causes queues to be disabled, but I don't see anything that indicates services can be disabled or deleted automatically.
When this happens, I usually have a large backlog of messages in multiple application queues, but nothing extreme. Total message backlog is around 200,000.
Does anyone know what might be happening here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您一定有某种发出 DROP SERVICE 语句的错误。这是删除服务的唯一方法。
检查默认跟踪，DROP 语句被跟踪并保存到其中这样您就可以追踪发出 DROP 的应用程序/用户/语句。检查 sys.traces 以查找默认跟踪的位置，然后打开Profiler 中的 .TRC 文件。
You must have a bug of some sort that issues a DROP SERVICE statement. That is the only way a service gets deleted.
Check the default trace, the DROP statement gets traced and saved into it so you can track down the application/user/statement that issues the DROP. Check sys.traces to find the location of the default trace then open the .TRC file in Profiler.