Question

我在SQL2005数据库中有一个负载很重的表（许多插入/更新/删除）。我想尽可能接近实时地对所有这些更改进行一些后期处理（异步以便不以任何方式锁定表）。我看了很多可能的解决方案，但似乎无法找到一个感觉正确的简洁解决方案。

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

所以，简单的问题仍然存在：表中的数据更改，我想在远程服务器上的c＃代码中进行一些处理。

目前我们已经提出使用一个sql触发器，它执行“xp_cmdshell”来启动一个exe，这会引发一个windows服务正在侦听的事件。这只是感觉不好。

然而，我在网上看到的其他解决方案也让人感到相当费解。例如，设置SQLCacheDependancy还涉及必须设置Service Broker。另一个可能的解决方案是使用CLR触发器，它可以调用Web服务，但是这里有很多关于它的警告，这是一个不好的方法，特别是在性能很关键时。

理想情况下，我们不会对表格进行更改，而是会拦截我们的应用程序中的调用并从那里通知服务，遗憾的是我们还有一些遗留应用程序也在对数据进行更改，并且监视表是唯一的目前集中的地方。

非常感谢任何帮助。

要点：

需要实时响应表数据更改
表现至关重要
预计会有大量流量
轮询和计划任务不是一种选择（或实时）
实施服务代理太大（但可能只是解决方案？）
CLR代码尚未排除，但如果建议
监听器/监听器可能是远程机器（可能是相同的物理网络）

Answer 1

您实际上没有很多方法可以检测SQL 2005中的更改。您已经列出了大部分更改。

查询通知。这是为SqlDependency及其衍生产品提供支持的技术，您可以在The Mysterious Notification上阅读更多详细信息。但QN旨在使结果无效，而不是主动通知更改内容。您只会知道该表有更改，而不知道更改了什么。在繁忙的系统上，这将无法正常工作，因为通知将会不断发生。

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

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

应用层。这是理论上的最佳选择，除非应用程序范围之外的数据发生变化，在这种情况下它会崩溃。实际上，在应用程序范围之外会发生始终更改。

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

总是建议做一个紧密耦合的同步通知（通过xp_cmdshell，xp_olecreate，CLR，通知WCF，你的名字），但所有这些方案在实践中都失败了，因为它们存在根本缺陷：
- 他们不考虑交易的一致性和回滚 - 它们引入了可用性依赖性（除非通知的组件在线，否则OLTP系统无法继续） - 它们执行得非常糟糕，因为每个DML操作都必须等待某种形式的RPC调用才能完成

如果触发器实际上没有主动通知侦听器，但只排队通知，则监视通知队列时出现问题（当我说'队列'时，我的意思是任何充当队列的表）。监控意味着拉动队列中的新条目，这意味着正确地平衡检查频率和更改负载，并对负载峰值做出反应。这根本不是微不足道的，实际上非常困难。但是，在SQL服务器中有一个语句具有阻止语义，而不会拉动，直到更改可用：WAITFOR(RECEIVE)。这意味着Service Broker。你在帖子中多次提到过SSB，但是你是非常正确的，因为很大的未知因素而害怕部署SSB。但实际情况是，到目前为止，它最适合您描述的任务。

您不必部署完整的SSB体系结构，其中通知一直传递到远程服务（无论如何都需要远程SQL实例，甚至是Express实例）。您需要共同的就是从发送通知的那一刻起（在提交更改之后）解除检测到更改的时刻（DML触发器）。为此，您需要的是本地SSB队列和服务。在触发器中，您SEND向本地服务发送更改通知。在原始DML事务提交之后，服务过程activates并使用CLR传递通知。您可以在Asynchronous T-SQL找到与此类似的示例。

如果你沿着这条道路前进，你需要学习一些技巧来实现高吞吐量，你必须理解SSB中有序传递信息的概念。我建议你阅读这些链接：

关于检测更改的方法，SQL 2008 显然添加了新选项：Change Data Capture and Change Tracking。我强调'显然'，因为它们不是真正的新技术。 CDC使用日志阅读器并基于现有的事务复制机制。 CT使用触发器，与现有的Merge复制机制非常相似。它们都适用于偶尔连接的系统，这些系统需要同步，因此不适合实时更改通知。他们可以填充更改表，但是您可以使用任务来监视这些表以进行更改，这完全取决于您从哪里开始。

Answer 2

这可以通过多种方式完成。下面的方法很简单，因为你不想使用CLR触发器和sqlcmd选项。

您可以创建普通插入触发器，而不是使用CLR触发器，更新每个插入的专用跟踪表。
开发专用窗口服务，主动轮询跟踪表并更新远程服务，如果数据有任何变化，并将跟踪表中的状态设置为完成（因此不会再次选择）。

修改

我认为ADO.Net的Microsoft同步服务可以为您服务。看看下面的链接。它可能会帮助你

How to: Use SQL Server Change Tracking - sql server 2008

Use a Custom Change Tracking System - below sql server 2008

Answer 3

在类似的情况下，我们正在使用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);
    }
}

Answer 4

由于您说该表上运行了很多插入，因此批处理可以更好地适应。

为什么只创建一个预定作业，处理由标志列标识的新数据，并以大块处理数据？

Answer 5

使用典型触发器在数据库上触发CLR。此CLR将仅使用Win32_Process类远程启动程序：

http://motevich.blogspot.com/2007/11/execute-program-on-remote-computer.html

如何通知DB表更改（sql 2005）的Windows服务（c＃）？

5 个答案: