何时使用CDC跟踪历史记录？

26

SQL Server更改数据捕获是一项功能，可从SQL Server事务日志中读取历史数据并将其存储在特殊表中。

然后，通过使用特殊的表值函数（TVF），它允许用户查询此数据，从而有可能获得特定表上的所有更改，或者仅获得特定时间内由更改导致的净更改。

CDC具有一定优势

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

它还有一些缺点：

历史数据的数量可以快速变得巨大。
您无法跟踪更改的对象（至少不能删除）。
由于历史数据是基于事务日志的，因此需要花费一些时间来追赶。
它取决于SQL Server代理。如果代理未运行或崩溃，则不会跟踪任何历史记录。

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

CDC对于哪些任务/方案是正确的工具？（例如，是否允许用户将数据对象还原到某个时间点？审核？显示数据的完整历史记录？）
您什么时候不应该使用CDC，而应该使用基于触发器的自定义解决方案？
是否可以在运营数据库中使用CDC并在运营应用程序中使用CDC数据？（例如，将其显示给最终用户）还是这显然是滥用此功能？

我通常听到CDC是一种审核工具，但是这不是SQL Server Audit的目的吗？它们是否都是用于同一任务的不同工具？还是CDC可以用于其他用途？

我目前的情况是要求我构建一个可靠的数据框架，该框架应该作为将来多个应用程序的基础。确切的要求是模糊的，但是一个要求是它应该能够跟踪数据历史记录，并将旧条目以及其他表中的所有相关数据还原。我现在正在评估CDC作为一种选择，但是不确定是否要这样做，因为我找不到真正推荐的用例。

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

sql-server change-data-capture data-versioning

— gna
source

1

理想情况下，“框架”不会做出这种决定。它将留给各个项目。但是由于要求您执行此操作，因此我至少要向提出您这些要求的人员指出：实现的方法有多种，并且最佳选择在很大程度上取决于确切的用法和需求。询问他们是否可以给您任何可能有助于您做出决定的说明（例如性能或灵活性是否更重要）。要考虑的另一种选择是将这两种选择都开发为“框架”的一部分，然后让实际项目选择启用哪一种。

— jpmc26 2014年

@ jpmc26，可能需要该框架来停止每个项目花费的时间来确定此类问题。

— 伊恩·林罗斯

@IanRingrose我的观点是，从长远来看，在不考虑项目特定需求的情况下做出决定将导致比解决方案更多的问题（因此，实际上花费的时间比花费的时间还多）。这是在一般情况下无法有效做出的决定。必须考虑项目的细节。使用总括决策，将花费时间使用所选的解决方案，并围绕它做出假设，仅当发现不适合的解决方案时才违反那些假设。然后，将需要重新设计系统。

— jpmc26 2014年

1

@ jpmc26我可能实际上会采用您提出的解决方案，以防万一我找到了实现它的方法：开发基于触发器和基于CDC的历史记录跟踪，可切换并在公共界面后面进行。然后，应用程序可以根据其需求选择其中一个，而不必担心自己实现。当然，我仍然想对上述问题得到一个很好的答案，因为如果无论如何CDC都不能用于此类任务（例如，因为它仅对审计有好处），我可能会省去麻烦，并且总是使用触发器。

— magnattic

“如果代理未运行或崩溃，则不会跟踪任何历史记录”-但是，如果重新启动它，则不会丢失任何更改，对吗？

— 安迪·乔纳

12

首先，

更改数据捕获仅在SQL Server的Enterprise，Developer和Evaluation版本上可用。

因此，这可以为您确定是否有任何客户没有企业版，或者您还不知道将使用企业版。（由于该规范包括“多个将来的应用程序”，对您来说可能是一个实际问题）

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

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

但是，您最好在应用程序级别解决此问题，方法是将所有更新写入消息队列，然后在任何给定时间点重播以创建数据库，请参见Martin Flowler博客上的Temporal Patterns，以获取有关选项的完整概述。

— 伊恩·林格罗斯
source

该链接是非常有趣的读物，对此表示感谢。在我看来，在应用程序级别解决此问题仍然不是一个选择。我正在构建的框架应该针对基于该框架的应用程序完成大部分工作，包括历史跟踪。然后，这些应用程序将使用通用接口来存储/检索数据，从而使他们不必关心数据的存储方式。我知道这个任务绝非易事。

— magnattic'4

另外，我目前不考虑企业版或不是决定本案的决定因素。我正在谈论的未来应用程序很可能全部由我们构建和托管。

— magnattic 2014年

@atticae，您的框架不必仅限于数据库，它可以包含在数据库外部运行的代码。

— 伊恩·林罗斯

当然，它不仅限于数据库。（在这种情况下，我不会将其称为框架。）我现在看到的是“应用程序级别”的含义，实际上，我实际上使用的是链接所讨论的Temporal Property模式的变体。我构建的框架为使用它的应用程序提供了此接口。尽管如此，这仍然是界面方面的一部分，而这一切都无法真正回答我上面概述的问题。

— magnattic'4

再次感谢您的回答。对于大多数人来说，这可能是决定因素，所以我认为这是一个很好的答案，并且可能会帮助将来的访客决定不使用CDC。但是，我觉得它并不能真正回答我的大多数问题，因此我将不得不向stacylaray赏金，他是唯一一个试图回答我所有问题的人。（尽管我希望得到一个更详细的答案。）

— 激进的2014年

12

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

— 布林
source

1

浏览完这篇文章后，我仍然不聪明。与大多数文章一样，它详细介绍了如何使用CDC以及如何将其与变更跟踪进行比较。但这并不能真正回答我的上述问题。

— magnattic'4

9

CDC对于哪些任务/方案是正确的工具？（例如，是否允许用户将数据对象还原到某个时间点？

也许，这取决于。

审核？

是。

显示完整的数据历史记录？）

是。

您什么时候不应该使用CDC，而应该使用基于触发器的自定义解决方案？

当变更表中的数据不能满足您的需求时。

是否可以在运营数据库中使用CDC并在运营应用程序中使用CDC数据？（例如，向最终用户展示）

是。

还是这显然是滥用此功能？

不，这不是滥用此功能。

我通常听到CDC是一种审核工具，但是这不是SQL Server Audit的目的吗？

是。

它们是否都是用于同一任务的不同工具？

没有。

还是CDC可以用于其他用途？

CDC可以用于其他用途。

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

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

另一方面，CDC会跟踪每一个小的变化，即历史。可以使用该历史记录来更新数据仓库，而不是批量复制数据，也可以使用该历史记录作为数据本身并根据该历史记录生成报告。变更表没有隐藏，也没有怪异的架构或其他内容。您可以查询它并使用所需的数据。请记住...这不是实时的，就像伊恩说的那样。数据来自事务日志，因此请像使用复制，镜像或日志传送一样进行处理。总的来说，它将比触发器更快。您将需要使用具有快照开销的快照隔离，并且您必须考虑灾难恢复。

— 斯泰西拉雷
source

2

纠正点。一次，更改数据捕获仅在以上列出的版本中可用。但是，从2016 SP1开始，更改数据捕获在标准版中可用。因此，在2016 SP1之前撰写的许多文章听起来似乎CDC对于使用Standard Edition的我们来说是遥不可及的。这已不再是这种情况。概述CDC可用性的Microsoft文档在下面的链接中。

https://docs.microsoft.com/zh-cn/sql/sql-server/editions-and-components-of-sql-server-2016?view=sql-server-2017#DW

— 罗伯特·西弗斯
source