Service Broker对话：结束或不结束™

Question

专家的时间（等待@RemusRusanu和伙伴^^）

上下文

我构建了一个服务代理程序，主要基于SQLTeam的博客示例（http://www.sqlteam.com/article/centralized-asynchronous-auditing-with-service-broker）来模拟同一SQL Server实例上两个数据库之间的ETL行为。几个小时经历了经纪人，对话，禁用队列，中毒消息，激活问题等等的技巧后，我终于开始工作了。

问题

为了使其更具生产性，我只需要处理以下主题：

1. 当消息队列清空时，不会从sys.conversation_endpoints中清除CLOSED状态会话：SQLTeam的示例在发起者或接收者端都没有提供任何END CONVERSATION，因此添加了评论

  

无需关闭对话，因为审核永远不会结束

在激活程序中。互联网充满了证据，不采取“一劳永逸”的行为。我在激活的程序结束时添加了一些END CONVERSATION，结果相同。大量使用过的对话。我知道重用对话框的好处（感谢@RemusRusanu），但我希望系统尽可能稳定，即避免耗尽可用的端点套接字。

=＆GT;我该怎么做呢？结束对话/不？有这种情况的生活时间吗？

1. 虽然正在使用TRY / CATCH，并且在回滚之后将INSERT语句置于，但已捕获的错误不会持久保存到Errors表中。

  ;SEND ON CONVERSATION @dlgId    
  MESSAGE TYPE [//Sync/Message] (@syncedData)
END TRY
BEGIN CATCH
  IF (XACT_STATE()) = -1
      ROLLBACK;

  INSERT INTO SyncErrors(ErrorProcedure, ErrorLine, ErrorNumber, ErrorMessage, ErrorSeverity, ErrorState, SyncedData)
  SELECT  ERROR_PROCEDURE(), ERROR_LINE(), ERROR_NUMBER(), ERROR_MESSAGE(), ERROR_SEVERITY(), ERROR_STATE(), @syncedData
END CATCH

=＆GT;为什么在错误引发时它永远不会起作用？

1. 在一些示例中，通信看起来像是通过交换不同的显式消息类型（错误和会话确认）来处理，在自定义XML消息的顶部。据我所知，这意味着两个＆＃34;交叉＆＃34;具有准确队列处理激活程序的端点（与我当前示例中的一个相比）。关于这个话题有很多意见，我有点困惑。几分钟前，我在@RemusRusanu发现了这篇很长的http://rusanu.com/2007/10/31/error-handling-in-service-broker-procedures文章，但直到现在还没有机会看一眼。

=＆GT;这会提供我正在寻找的稳定性和稳健性吗？

1. 最后但最不重要。我最近遇到了70 + GB意外的系统卷实现（顺便说一下，Windows事件日志），连续2天，与服务代理使用一致，搞砸了我的虚拟机，直到找到根本原因（感谢Treesize Professional工具） ）。

=＆GT;这是正常的行为吗？有什么方法可以避免这种冗长，限制事件日志增长或配置轮换周期？

非常感谢你把我带到原力的阴暗面：）