如何通知DB表更改（sql 2005）的Windows服务（c＃）？
我在SQL2005数据库中有一个负载很重的表（许多插入/更新/删除）。 我想尽可能接近实时地对所有这些更改进行一些后期处理（异步，以免以任何方式锁定表）。 我看了很多可能的解决方案，但似乎无法找到一个感觉正确的整洁解决方案。
后期处理的类型也相当繁重，以至于Windows侦听器服务实际上将处理传递给许多机器。 然而，应用程序的这一部分已经启动并运行，完全异步，而不是我需要帮助 – 我只是想提及这只是因为它影响了设计决策，因为我们不能只加载一些CLR对象DB完成处理。
所以，简单的问题仍然存在：表中的数据更改，我想在远程服务器上的c＃代码中进行一些处理。
目前我们已经提出使用一个sql触发器，它执行“xp_cmdshell”来启动一个exe，它引发了一个windows服务正在侦听的事件。 这只是感觉很糟糕。
但是，我在网上看到的其他解决方案也让人感到相当费解。 例如，设置SQLCacheDependancy还需要设置Service Broker。 另一种可能的解决方案是使用CLR触发器，它可以调用Web服务，但是在线上有很多警告，这是一种不好的方法，尤其是在性能至关重要时。
理想情况下，我们不会在表格上进行更改，而是在我们的应用程序中拦截调用并从那里通知服务，遗憾的是我们还有一些遗留应用程序也在对数据进行更改，并且监控表格是唯一的集中位置此时此刻。
非常感激任何的帮助。
摘要：
- 需要实时响应表数据的变化
- 绩效至关重要
- 预计会有大量的流量
- 轮询和计划任务不是一种选择（或实时）
- 实施服务代理太大（但可能只是解决方案？）
- CLR代码尚未排除，但如果建议则需要执行
- 监听器/监视器可能是远程机器（可能是相同的物理网络）
您确实没有很多方法可以检测SQL 2005中的更改。您已经列出了大部分内容。
查询通知 。 这是支持SqlDependency及其衍生产品的技术，您可以阅读有关The Mysterious Notification的更多详细信息。 但QN旨在使结果无效 ，而不是主动通知更改内容。 您只会知道该表有更改，而不知道更改了什么。 在繁忙的系统上，这将无法正常工作，因为通知将不断发生。
日志阅读 。 这是事务复制使用的，也是检测更改的最少侵入性方法。 不幸的是，仅适用于内部组件。 即使您设法了解日志格式，问题在于您需要引擎支持将日志标记为“正在使用”，直到您阅读它，否则它可能会被覆盖。 只有事务复制才能执行此类特殊标记。
数据比较 。 依靠timestamp列来检测更改。 也是基于拉力，非常具有侵略性并且在检测删除方面存在问题。
应用层 。 这是理论上的最佳选择，除非应用程序范围之外的数据发生变化，在这种情况下它会崩溃。 实际上，在应用程序范围之外总会发生变化。
触发器 。 最终，这是唯一可行的选择。 基于触发器的所有更改机制都以相同的方式工作，它们将更改通知排队到监视队列的组件。
总是建议做一个紧密耦合的同步通知（通过xp_cmdshell，xp_olecreate，CLR，通知WCF，你给它命名），但所有这些方案在实践中都失败了，因为它们从根本上是有缺陷的：
– 它们不考虑事务一致性和回滚
– 它们引入了可用性依赖性（除非通知的组件在线，否则OLTP系统无法继续）
– 它们执行起来非常糟糕，因为每个DML操作都必须等待某种forms的RPC调用才能完成
如果触发器实际上没有主动通知侦听器，但只排队通知，则监视通知队列时出现问题（当我说’队列’时，我的意思是任何充当队列的表）。 监控意味着拉动队列中的新条目，这意味着正确地将检查频率与更改负载进行平衡，并对负载峰值做出反应。 这根本不是微不足道的，实际上是非常困难的。 但是，在SQL服务器中有一个语句具有阻止语义，无需拉动，直到更改变为可用： WAITFOR（RECEIVE） 。 这意味着Service Broker。 你在post中多次提到过SSB，但是你是非常正确的，因为很大的未知因素而害怕部署SSB。 但实际情况是，到目前为止，它最适合您描述的任务。
您不必部署完整的SSB体系结构，其中通知一直传递到远程服务（无论如何都需要远程SQL实例，甚至是Express实例）。 您需要共同做的就是从发送通知的那一刻起（在提交更改之后）解耦检测到更改的时刻（DML触发器）。 为此，您需要的是本地SSB队列和服务。 在触发器中，您向本地服务发送更改通知。 在原始DML事务提交之后，服务过程激活并传递通知，例如使用CLR。 您可以在Asynchronous T-SQL中看到与此类似的示例。
如果你沿着这条路走下去，你需要学习一些技巧来实现高吞吐量，你必须理解SSB中有序传递消息的概念。 我推荐你阅读这些链接：
- 重用对话
- 编写服务代理程序
- SQL Connections 2007演示
关于检测更改的方法，SQL 2008 显然添加了新选项： 更改数据捕获和更改跟踪 。 我强调’显然’，因为它们不是真正的新技术。 CDC使用日志阅读器，它基于现有的事务复制机制。 CT使用触发器，与现有的Merge复制机制非常相似。 它们都用于偶尔连接的系统，这些系统需要同步，因此不适合实时更改通知。 他们可以填充更改表，但是您可以使用任务来监视这些表以进行更改，这完全取决于您从何处开始。
这可以通过多种方式完成。 下面的方法很简单，因为你不想使用CLR触发器和sqlcmd选项。
-
您可以创建正常的插入触发器来更新每个插入的专用跟踪表，而不是使用CLR触发器。
-
并开发专用窗口服务，主动轮询跟踪表并更新远程服务，如果数据有任何变化，并将跟踪表中的状态设置为完成（因此不会再次选择）。
编辑：
我认为ADO.Net的Microsoft同步服务可以为您服务。 看看下面的链接。 它可能会帮助你
- 如何：使用SQL Server更改跟踪 – sql server 2008
- 使用自定义更改跟踪系统 – 在sql server 2008下面
在类似情况下，我们使用CLR触发器将消息写入队列（MSMQ）。 用C＃编写的服务正在监视队列并进行后处理。 在我们的例子中，它完全在同一台服务器上完成，但你可以将这些消息直接发送到另一台机器上的远程队列，完全绕过“本地监听器”。
从触发器调用的代码如下所示：
public static void SendMsmqMessage(string queueName, string data) { //Define the queue path based on the input parameter. string QueuePath = String.Format(".\\private$\\{0}", queueName); try { if (!MessageQueue.Exists(QueuePath)) MessageQueue.Create(QueuePath); //Open the queue with the Send access mode MessageQueue MSMQueue = new MessageQueue(QueuePath, QueueAccessMode.Send); //Define the queue message formatting and create message BinaryMessageFormatter MessageFormatter = new BinaryMessageFormatter(); Message MSMQMessage = new Message(data, MessageFormatter); MSMQueue.Send(MSMQMessage); } catch (Exception x) { // async logging: gotta return from the trigger ASAP System.Threading.ThreadPool.QueueUserWorkItem(new WaitCallback(LogException), x); } } 既然你说在那张桌子上运行了很多插件，那么批量处理可能更合适。
为什么只创建一个预定作业，它处理由标志列标识的新数据，并以大块处理数据？
使用典型触发器在数据库上触发CLR。 此CLR将仅使用Win32_Process类远程启动程序：
http://motevich.blogspot.com/2007/11/execute-program-on-remote-computer.html