何时使用 CDC 跟踪历史?

mag*_*tic 27 sql-server change-data-capture data-versioning

SQL Server Change Data Capture 是一项从 SQL Server 事务日志中读取历史数据并将其存储在特殊表中的功能。

通过使用特殊的表值函数 (TVF),它允许用户查询这些数据,从而可以获取特定表上的所有更改或仅获取特定时间内更改导致的净更改。

CDC具有一定的优势

  • 它可以配置为仅跟踪某些表或列。
  • 它能够在一定程度上处理模型更改。
  • 它不会像触发器那样严重影响性能,因为它与事务日志一起工作。
  • 它很容易启用/禁用,并且不需要表上应跟踪的其他列。

它也有一些缺点:

我已经阅读了很多关于 CDC 的文章,虽然我现在知道如何使用它,但我仍然不确定它是否适合我。

  1. CDC 适合哪些任务/场景?(例如,允许用户将数据对象恢复到某个时间点?审计?显示数据的完整历史记录?)
  2. 何时不应使用 CDC,而应求助于基于触发器的自定义解决方案?
  3. 在操作数据库中使用 CDC 并在操作应用程序中使用 CDC 数据是否可以?(例如,将其展示给最终用户)或者这显然是对该功能的滥用?

我经常听说 CDC 是一个审计工具,但这不是SQL Server 审计的用途吗?它们是用于同一任务的不同工具吗?或者CDC可以用于其他用途吗?

我目前的情况是,我被要求构建一个可靠的数据框架,该框架应该是未来多个应用程序的基础。确切的要求是模糊的,但其中之一是它应该能够跟踪数据历史并将旧条目与其他表中的所有相关数据一起恢复。我现在正在评估 CDC 作为一种选择,但不确定这是否是可行的方法,因为我真的找不到任何推荐的用例。

虽然我很欣赏针对我的特定场景的建议,但答案应该提供有关何时或何时不使用 Change Data Capture 的一般建议。

Ian*_*ose 13

首先,

更改数据捕获仅适用于 SQL Server 的 Enterprise、Developer 和 Evaluation 版本。

因此,这可能会为您决定是否有任何客户没有企业版,或者您还不知道您将使用企业版。(由于规范包括“多个未来应用程序”,这对您来说可能是一个真正的问题)

与触发器不同,它不是实时的,这既是优点也是缺点。使用触发器总是会减慢更新速度。

当我们使用触发器(由 CodeSmith 生成)时,我在一个系统上工作,以及跟踪对记录的所有更改,我们还将这些更改链接到一个“历史”表,其中包含进行更改的应用程序模块,以及用户用来进行更改的 UI 项。

但是,您可能最好在应用程序级别解决此问题,例如将所有更新写入消息队列,然后在任何给定时间点重播该队列以创建数据库,请参阅Martin Flowler 博客上的 Temporal Patterns 以获得选项的良好概述。


bry*_*ynn 12

这是一个写得很好的 9 部分系列,回顾了审计 SQL Server 数据更改的不同方法。第 3、4 和 5 部分侧重于 CDC。阅读所有文章都是值得的,因为这将回答您的问题,例如不同场景中的功能适合和开销。 http://solutioncenter.apexsql.com/tag/methods-for-auditing-sql-server


sta*_*ray 9

CDC 适合哪些任务/场景?(例如,允许用户将数据对象恢复到某个时间点?

也许,这取决于。

审计?

是的。

显示数据的完整历史?)

是的。

何时不应使用 CDC,而应求助于基于触发器的自定义解决方案?

当变更表中的数据不符合您的需求时。

在操作数据库中使用 CDC 并在操作应用程序中使用 CDC 数据是否可以?(例如向最终用户展示)

是的。

或者这显然是对该功能的滥用?

不,这不是滥用此功能。

我经常听说 CDC 是一种审计工具,但这不是 SQL Server 审计的用途吗?

是的。

它们是用于同一任务的不同工具吗?

不。

或者CDC可以用于其他用途吗?

CDC 可用于其他用途。

有变更跟踪和变更数据捕获。两者都源于复制。

更改跟踪提供了一种向表提供净更改的方法。一个使用示例是手持设备同步。

另一方面,CDC 会跟踪每一个微小的变化,即一段历史。可以使用该历史来更新数据仓库而不是批量复制数据,或者可以使用该历史作为数据本身并从中生成报告。更改表不是隐藏的,也没有一些奇怪的模式或其他东西。您可以查询它并根据需要使用数据。请记住……这不是实时的,就像伊恩说的那样。数据来自事务日志,因此请像使用复制、镜像或日志传送一样处理它。总的来说,它会比触发器更快。您将需要使用具有开销的快照隔离,并且您将不得不考虑灾难恢复。