在 SQL Server 中手动清理 CHANGE TRACKING答案

【问题标题】：Manually cleanup CHANGE TRACKING in SQL Server在 SQL Server 中手动清理 CHANGE TRACKING
【发布时间】：2018-11-28 16:51:24
【问题描述】：

我正在尝试手动清理 SQL Server 2017 中的更改跟踪表。

我运行命令

exec sp_flush_CT_internal_table_on_demand 'mydb.data.foobar'

错误信息：

消息 2501，级别 16，状态 1，过程 sys.sp_MSflush_CT_internal_table_on_demand，第 22 行 [批处理开始第 40 行]
找不到名为“mydb.data.foobar”的表或对象。检查系统目录。

“mydb.data.foobar”表确实存在。

以下成功返回：

select object_id('mydb.data.foobar')

有人手动清洁过 CT 吗？

【问题讨论】：

【解决方案1】：

有一个系统存储过程可用sys.sp_flush_commit_table_on_demand，以防我们想要使用可配置的批量大小进行手动清理。但是，只有在您无法通过自动清理来管理更改跟踪内部表的情况下，才应使用它。

您还应该在运行手动清理时禁用自动清理，否则它们可能会相互阻塞。

EXEC sp_flush_commit_table_on_demand 100000

使用这样的东西：

EXEC sys.sp_flush_CT_internal_table_on_demand 'Table_Name'

它对我有用。我想你错过了sys.

设置auto_cleanup = false 基本上意味着禁用清理，这允许您在遇到需要调试/调查的同步问题时进行任何故障排除。

【讨论】：

【解决方案2】：

这里的问题已经有好几年了，但我今天偶然发现了一个解决方案，因为我也遇到了这个问题多年。

对于将更改跟踪结合使用 Logging 设置为 Simple 以外的其他内容的任何人，请参阅 KB4500403 并确保您已安装最新的累积更新。

本文涉及大型事务日志，但它也解决了更改跟踪清理通常无法正常工作的问题。在我安装此累积更新之前，我不仅无法运行更改跟踪清理，而且我还不得不禁用自动清理，因为它整天保持 100% 的 CPU 内核并为高度活跃的数据库生成 50GB 以上的日志文件。

【讨论】：