【问题标题】:Manually delete change tracking records in SQL Server手动删除 SQL Server 中的更改跟踪记录
【发布时间】:2015-06-23 02:40:14
【问题描述】:

在客户端更新后,我找不到任何方法来手动清理更改跟踪表。这似乎是 SQL Server 中更改跟踪的主要限制,除非我遗漏了什么。

也许我忽略了一些东西,但我想要完成的是在客户端从 SQL Server 成功更新以删除更改表中的那些更改记录之后。那时不需要它们。

我知道的唯一配置是 2 天的保留期......等等。因为不同的客户/人将以非常不同的时间间隔同步,所以我唯一的选择似乎是设置一个非常长的保留期:例如365 天。但是这样做会导致膨胀,一旦所有客户端都更新后无法清除。

因此,似乎唯一的解决方法是手动创建触发器并维护我自己的删除表、更新表等。

有没有人找到更好的方法来管理此问题,而不是简单地不使用已实施的更改跟踪功能?

【问题讨论】:

    标签: sql-server change-tracking


    【解决方案1】:

    将您的保留期设置为合理且实用的时间长度。如果客户端尝试使用过期版本(在sys.change_tracking_tables 中小于min_valid_version)进行同步,它必须重新同步整个表。希望您没有太多客户等待数月同步。如果是这样……至少他们不经常这样做。

    【讨论】:

    • 是的,我想只要客户端在完整下载之前发送更改,这可能是可以接受的。我只是希望对这个配置有更多的控制。
    【解决方案2】:

    没有完美的解决方案,但对于空间密集型服务器,我已删除表并从副本重新创建,然后重新启用更改跟踪。这删除了该表的所有更改跟踪记录。我这样做是定期维护的一部分。

    我已使用 sys.sp_cdc_disable_db 在维护期间禁用更改跟踪以简化此过程。

    在采用这种方法之前,我已经实现了自己的跟踪系统。但是由于复制、远程和故障转移服务器问题,跟踪所有这些更改变得非常复杂。这是一种痛苦,特别是如果一个人已经实现了自动恢复功能。开销不值得。

    希望这会有所帮助。

    【讨论】:

    • 谢谢...是的,我不想承担引导的开销。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2017-09-05
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-03-04
    相关资源
    最近更新 更多