管理更改跟踪（SQL Server）

本主题介绍如何管理更改跟踪。它还介绍了如何在使用更改跟踪时配置安全性并确定对存储和性能的影响。

管理变更跟踪

以下部分列出了与管理更改跟踪相关的目录视图、权限和设置。

若要确定哪些表和数据库已启用更改跟踪，可以使用以下目录视图：

此外， sys.internal_tables 目录视图列出了为用户表启用更改跟踪时创建的内部表。

若要使用更改跟踪函数访问更改跟踪信息，主体必须具有以下权限：

对要查询的表的更改跟踪表上至少具有主键列的 SELECT 权限。
要获取更改的表的 VIEW CHANGE TRACKING 权限。 VIEW CHANGE TRACKING 权限是必需的，原因如下：
- 更改跟踪记录包括有关已删除的行的信息，特别是已删除的行的主键值。主体可能已被授予对变更跟踪表的 SELECT 权限，前提是在一些敏感数据被删除之后。在这种情况下，你不希望该权限持有人能够通过更改跟踪功能访问已删除的信息。
- 更改跟踪信息可以存储有关哪些列已被更新操作更改的信息。可以拒绝负责人访问包含敏感信息的列的权限。但是，由于更改跟踪信息可用，主体可以确定列值已更新，但主体无法确定列的值。

为表启用更改跟踪后，一些管理操作将受到影响。下表列出了您应考虑的操作及其效果。

操作	启用更改跟踪时
删除表	已删除表的所有更改跟踪信息都将被删除。
ALTER TABLE 删除约束条件	尝试删除 PRIMARY KEY 约束将失败。必须先禁用更改跟踪，然后才能删除 PRIMARY KEY 约束。
修改数据表删除列	如果正在删除的列是主键的一部分，则无论更改跟踪如何，都不允许删除该列。如果正在删除的列不是主键的一部分，则删除列会成功。但是，应首先了解同步此数据的任何应用程序的影响。如果为表启用了列更改跟踪，则删除的列可能仍作为更改跟踪信息的一部分返回。应用程序负责处理已删除的列。
修改表添加列	如果将新列添加到更改跟踪表，则不会跟踪该列的添加。仅跟踪与新列相关的更新和更改。
ALTER 表 ALTER 列	不跟踪非主键列的数据类型更改。
变更表开关	如果一个或两个表都启用了更改跟踪，切换分区将失败。
DROP INDEX 或 ALTER INDEX DISABLE	无法删除或禁用强制实施主键的索引。
TRUNCATE TABLE（删除表中所有数据）	可以对启用了更改跟踪的表执行截断操作。操作删除的行不会被跟踪，并且最低有效版本会被更新。当应用程序检查其版本时，该检查指示版本太旧且需要重新初始化。表现出来的效果就像是先禁用了更改跟踪，然后为表重新启用了它。

使用变更跟踪确实会增加 DML 操作的一些开销，因为变更跟踪信息是作为该操作的一部分存储的。

已优化更改跟踪，以最大程度地减少 DML 操作的性能负担。与对表使用更改跟踪关联的增量性能开销类似于为表创建索引时产生的开销，需要维护。

对于每一行被 DML 操作更改时，会在内部更改跟踪表中添加一行。这相对于 DML操作的效果取决于各种因素，例如：

如果使用快照隔离，它也会影响所有DML操作的性能，无论是否启用更改跟踪。

更改跟踪数据存储在以下类型的内部表中：

这些内部表通过以下方式影响存储要求：

对于用户表中每行的每一次更改，都会在内部更改表中添加一行。此行具有较小的固定开销，以及等于主键列大小的可变开销。该行可以包含应用程序设置的可选上下文信息。如果启用了列跟踪，则每个更改的列都需要跟踪表中的 4 个字节。
对于每个提交的事务，会添加一行到内部事务表中。

与其他内部表一样，可以使用 sp_spaceused 存储过程来确定用于更改跟踪表的空间。可以使用 sys.internal_tables 目录视图获取内部表的名称，如以下示例所示。

sp_spaceused 'sys.change_tracking_309576141'  
sp_spaceused 'sys.syscommittab'