17

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

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

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

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

然而，我在网上看到的其他解决方案也感觉相当复杂。例如，设置 SQLCacheDependancy 还需要设置服务代理。另一种可能的解决方案是使用 CLR 触发器，它可以调用 web 服务，但是网上有很多警告说这是一种不好的方法，尤其是在性能至关重要的时候。

理想情况下，我们不会依赖表更改，而是会拦截应用程序内部的调用并从那里通知服务，不幸的是，尽管我们有一些遗留应用程序也对数据进行更改，并且监控表是唯一集中的地方此时此刻。

非常感激任何的帮助。

概括：

  • 需要实时响应表数据变化
  • 性能至关重要
  • 预计会有高流量
  • 轮询和计划任务不是一个选项（或实时）
  • 实施服务代理太大（但可能是唯一的解决方案？）
  • CLR 代码尚未排除，但如果建议，则需要 perfomant
  • 监听器/监视器可能是远程机器（可能是同一个物理网络）
4

5 回答 5

20

您确实没有那么多方法来检测 SQL 2005 中的更改。您已经列出了其中的大部分。

查询通知。这是支持 SqlDependency 及其衍生产品的技术，您可以阅读The Mysterious Notification 的更多详细信息。但 QN 旨在使结果无效，而不是主动通知更改内容。你只会知道表发生了变化，而不知道发生了什么变化。在繁忙的系统上，这是行不通的，因为通知会持续不断地出现。

日志阅读。这是事务复制使用的方式，并且是检测更改的最少干扰方式。不幸的是，仅适用于内部组件。即使您设法理解日志格式，问题是您需要引擎的支持才能将日志标记为“正在使用”，直到您阅读它，否则它可能会被覆盖。只有事务复制可以做这种特殊的标记。

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

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

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

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

如果触发器实际上并没有主动通知侦听器，而只是将通知排队，那么监控通知队列就会出现问题（当我说“队列”时，我指的是任何充当队列的表）。监控意味着在队列中拉取新条目，这意味着正确平衡检查频率与更改负载，并对负载峰值做出反应。这一点都不是小事，实际上是非常困难的。但是，SQL Server 中有一条语句具有阻塞的语义，无需拉取，直到更改可用：WAITFOR(RECEIVE)。这意味着服务代理。您在帖子中多次提到 SSB，但您理所当然地害怕部署它，因为存在很大的未知数。但现实情况是，到目前为止，它最适合您描述的任务。

您不必部署完整的 SSB 架构，其中通知一直传递到远程服务（无论如何这将需要远程 SQL 实例，甚至是 Express 实例）。您需要做的就是将检测到更改的时刻（DML 触发器）与传递通知的时刻（提交更改之后）分离。为此，您只需要一个本地 SSB 队列和服务。在触发器中，您向本地服务发送更改通知。在原始 DML 事务提交后，服务过程会激活并传递通知，例如使用 CLR。您可以在Asynchronous T-SQL中看到与此类似的示例。

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

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

于 2009-10-13T18:24:59.410 回答
1

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

  • 您可以创建普通的插入触发器，而不是使用 CLR 触发器，它会在每次插入时更新专用跟踪表。

  • 并开发专门的窗口服务，主动轮询跟踪表，如果数据有任何变化，更新远程服务，并将跟踪表中的状态设置为完成（这样就不会再次被选中）。

编辑：

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

于 2009-10-13T11:31:35.297 回答
0

在类似的情况下，我们使用将消息写入队列 (MSMQ) 的 CLR 触发器。用 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);
    }
}
于 2009-10-13T20:49:53.877 回答
-1

由于您说该表上运行了许多插入，因此批处理可能更适合。

为什么只创建一个计划作业，它处理由标志列标识的新数据，并以大块的形式处理数据？

于 2009-10-13T11:21:01.217 回答
-1

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

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

于 2009-10-13T14:02:22.867 回答