c# - 如何通知Windows服务(C#)数据库表更改(sql 2005)？

Question

我在SQL2005数据库中有一个负载很重的表(很多插入/更新/删除)。我想对所有这些更改进行一些后期处理，以尽可能接近实时(异步操作，以免以任何方式锁定表)。我看过许多可能的解决方案，但似乎找不到适合的整洁解决方案。

后处理的种类也相当繁重，以至于Windows侦听器服务实际上会将处理传递给许多机器。但是，应用程序的这一部分已经启动并运行，完全是异步的，不是我需要的帮助-我只想提及这一点，因为它会影响设计决策，因为我们不能只在其中加载一些CLR对象。 DB完成处理。

因此，简单的问题仍然存在:表中的数据更改，我想在远程服务器上的C#代码中进行一些处理。

目前，我们已经提出了使用sql触发器的方法，该触发器执行“xp_cmdshell”来启动一个exe，该exe引发Windows服务正在侦听的事件。这真让人难过。

但是，我在网上看到的其他解决方案也相当复杂。例如，设置SQLCacheDependancy还涉及必须设置服务代理。另一种可能的解决方案是使用CLR触发器，该触发器可以调用Web服务，但是在线上有很多警告说这是执行该操作的不好方法，尤其是在性能至关重要的情况下。

从概念上讲，我们不会依赖表更改，而是宁愿拦截应用程序内的调用并从那里通知服务，不幸的是，尽管我们也有一些旧应用程序也在对数据进行更改，并且监视表是唯一的集中位置此时此刻。

非常感激任何的帮助。

概括:

需要实时响应表数据更改

性能至关重要

预计交通量

轮询和计划任务不是选项(或实时)

实现服务代理太大(但可能只是解决方案？)

CLR代码尚未排除，但如果建议使用

，则需要执行此操作

侦听器/监视器可能是远程计算机(可能是同一物理网络)

Answer 1

实际上，您没有太多方法可以检测到SQL 2005中的更改。您已经列出了大多数方法。

查询通知。这是支持SqlDependency及其派生工具的技术，您可以阅读有关The Mysterious Notification的更多详细信息。但是，QN旨在使结果无效，而不是主动通知更改内容。您将只知道表已更改，而不知道更改了什么。在繁忙的系统上，这将不起作用，因为通知将连续不断地发出。

日志读取。这就是事务复制所使用的东西，并且是检测更改的侵入性最小的方法。不幸的是，仅适用于内部组件。即使您设法了解了日志格式，问题仍然是您需要引擎的支持才能将日志标记为“正在使用”，直到您阅读它为止，否则它可能会被覆盖。只有事务复制才能执行这种特殊标记。

数据比较。依靠时间戳列来检测更改。也是基于拉取的，非常具有侵入性，并且在检测删除时存在问题。

应用程序层。从理论上讲，这是最好的选择，除非在应用程序范围之外发生数据更改，否则数据将崩溃。实际上，在应用程序范围之外总会发生变化。

触发。最终，这是唯一可行的选择。所有基于触发器的变更机制都以相同的方式工作，它们将变更通知排队到监视队列的组件。

总是建议进行紧密耦合的同步通知(通过xp_cmdshell，xp_olecreate，CLR，使用WCF进行通知，您可以将其命名)，但是所有这些方案在实践中均会失败，因为它们从根本上来说是有缺陷的:
-他们不考虑交易的一致性和回滚
-它们引入了可用性依赖性(除非所通知的组件在线，否则OLTP系统无法继续进行)
-由于每个DML操作都必须等待某种形式的RPC调用完成，因此它们的执行效果令人恐惧

如果触发器实际上没有主动通知侦听器，而只是将通知排队，则监视通知队列存在问题(当我说“队列”时，是指充当队列的任何表)。监视意味着拉出队列中的新条目，这意味着在检查频率与更改负载之间保持平衡，并对负载峰值使用react。这一点都不微不足道，实际上是很难的。但是，SQL Server中有一个语句具有要阻止的语义(无需拉出)，直到更改可用为止:WAITFOR(RECEIVE)。这意味着服务经纪人。您曾在帖子中多次提及SSB，但是，正因为如此，您不敢部署SSB，这是一个很大的未知数。但事实是，到目前为止，它最适合您描述的任务。

您不必部署完整的SSB体系结构，在该体系结构中，通知会一直传递到远程服务(无论如何，这都将需要一个远程SQL实例，甚至需要一个Express SQL实例)。您所需要做的就是将检测到更改的那一刻(DML触发器)与传递通知的那一刻(提交更改后)分开。为此，您需要的是本地SSB队列和服务。在触发器中，您SEND对本地服务的更改通知。在原始DML事务提交后，服务过程activates并使用CLR传递通知。您可以在Asynchronous T-SQL看到类似的示例。

如果您走这条路，那么您将需要学习一些技巧以实现高吞吐量，并且您必须理解SSB中消息有序传递的概念。我建议您阅读以下链接:

Reusing Conversations

Writing Service Broker Procedures

SQL Connections 2007 Demo

关于检测更改的方法，SQL 2008显然添加了新选项: Change Data Capture and Change Tracking。我强调“显然”，因为它们并不是真正的新技术。 CDC使用日志读取器，并基于现有的事务复制机制。 CT使用触发器，并且与现有的“合并”复制机制非常相似。它们都用于 偶尔连接的系统，这些系统需要同步，因此不适用于实时更改通知。它们可以填充变更表，但是您剩下的任务就是监视这些表中的变更，而这恰恰是从您开始的地方开始的。