变更数据捕获性能损失是否仅限于启用 CDC 的表？

发布于 2024-10-05 21:17:33 字数 236 浏览 1 评论 0原文

我读到启用更改数据捕获显然会对数据库性能产生影响。这种性能损失是否只会影响启用了 CDC 的表，还是会影响数据库中的所有操作？

在我的情况下，我正在使用 SSIS，并且有大量数据移入和移出临时数据库。我的系统中还有一些用于转换的查找表。我希望使用 CDC 作为仅审核这些引用表（而不是导入的数据）的更改的方法。我作为 ETL 的一部分运行的主要查询访问这些参考表，但不更改它们，因此我试图弄清楚是否仍然会有明显的性能影响？

谢谢

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

相对绾红妆 2024-10-12 21:17:33

这个问题的答案既是肯定的，也是否定的。

不，因为

当表启用更改数据捕获时，关联的捕获
创建实例是为了支持
传播变更数据
源表。捕获实例
由一个变更表组成，最多
两个查询功能。

未跟踪的表似乎不参与跟踪数据。

是的，因为

变更的变更数据来源
数据捕获是SQL Server
交易日志。作为插入、更新、
并将删除应用于跟踪
源表，描述的条目
这些更改将添加到日志中。
日志作为更改的输入
数据捕获过程。这
读取日志并添加信息
关于跟踪表的更改
关联的变更表。

由于更改的来源来自事务日志，因此更改的传播需要捕获实例读取并解释事务日志（免责声明：我对事物的解释）。仅启用 CDC 就会对整个数据库产生性能影响。

建议

存储：
在规划变更数据捕获架构时，请考虑日志大小和日志量 I/O 操作的显着增加。
考虑在 sys.sp_cdc_enable_table 中指定文件组。
在执行 sys.sp_cdc_enble_db 之前，请考虑更改数据库的默认文件组，以便更改数据捕获元数据（尤其是 cdc.lsn_time_mappings）位于与 PRIMARY 不同的文件组上。
工作负载行为：
尽量避免出现插入后需要立即更新行的情况。
尽量避免使用更改数据捕获来捕获对频繁进行大型更新事务的表的更改。
更改数据捕获参数：
始终将变更数据捕获捕获的列列表减少到仅您真正需要跟踪的列。
如果您不需要支持净更改，请将 @ 设置为 0。
用于查看变更数据捕获是否能够跟上您的工作负载。
如果变更数据捕获无法跟上您的工作负载，请修改扫描作业参数并重新启动扫描作业。

结论
如果您的服务器当前在跟上其负载方面没有问题，我非常怀疑您是否会注意到为不经常更改的表启用 CDC 时出现的任何性能问题。

来源

The answer to that question would be both yes and no.

No because

When a table is enabled for change data capture, an associated capture
instance is created to support the
dissemination of the change data in
the source table. The capture instance
consists of a change table and up to
two query functions.

Untracked tables seem not to be not involved in tracking data.

Yes because

The source of change data for change
data capture is the SQL Server
transaction log. As inserts, updates,
and deletes are applied to tracked
source tables, entries that describe
those changes are added to the log.
The log serves as input to the change
data capture process. This
reads the log and adds information
about changes to the tracked table’s
associated change table.

As the source of changes come from the transaction log, dissemination of the the changes requires the capture instances to read and interprete the transaction log (disclaimer: my interpretation of things). Merely enabling CDC has a performance impact on your entire database.

Recommendations

Storage:
When planning change data capture architecture, take a significant increase in log size and log volume I/O operations into account.
Consider specifying a filegroup in sys.sp_cdc_enable_table.
Consider changing the default filegroup for the database before you execute sys.sp_cdc_enble_db so that change data capture metadata and especially cdc.lsn_time_mappings are located on a different filegroup than PRIMARY.
Workload behavior:
Try to avoid scenarios where a row needs to be updated immediately after insert.
Try to avoid using change data capture to capture changes to tables that have frequent large update transactions.
Change data capture parameters:
Always reduce the list of columns captured by change data capture to only the columns you really need to track.
If you do not require support for net changes, set @ to 0.
Use to see whether change data capture can keep up with your workload.
If change data capture cannot keep up with your workload, modify scan job parameters and restart the scan job.

Conclusion
If your server currently has no problems keeping up with its load, I very much doubt you'll notice any performance problems enabling CDC for infrequent changed tables.

Sources

回复收藏 0 原文

~没有更多了~