• 对于捕获的数据变化信息，有内置的清理机制；
• 提供函数捕获变化信息；
• 可以使用标准工具进行配置和管理；

cdc.fn_cdc_get_net_changes_dbo_VW_GHZDK：针对指定 LSN 范围内每个已更改的源行返回一个净更改行。也就是说，如果在 LSN 范围内源行具有多项更改，则该函数将返回反映该行最终内容的单一行

1. 在启用cdc之后，表新加的列不捕获变化；
2. 如果跟踪的列删除了，那么会补空值；
3. 如果列数据类型变化了，那么相应的change table中也会变化；
   

捕获作业与事务复制日志读取之间的关系

cdc的捕获进程逻辑写在过程sp_replcmds（为sqlserver.exe的一部分；同样也用于读取事务日志）中。

注：如果开启了CDC，若有变化未获取，则即使将恢复模式设置为simple，事务日志也不会截断。即使使用checkpoint也不可以。

有关cdc，有两个代理任务：

capture job每个循环最多扫描1000个事务，循环间的间隔为5秒；
清理作业在每天的2点运行。保留change table中的数据3天，每个delete语句最多删除5000条数据。

cdc agent job可以使用以下过程添加和删除：
更改cdc agent job的默认值的存储过程（需要重启job）：

如果数据库与表列的排序规则不同，则cdc可能会使用，可以通过为列使用nvarchar或nchar来解决这个问题。

如果数据库中已经存在了cdc用户或模式，则无法启用cdc。

禁用数据库级别的cdc之前无需禁用表级别cdc。库级别禁用cdc会删除cdc相关的元数据、包含cdc用户和架构及cdc job。

如果删掉了启用cdc的数据库，则相应的cdc job也会自动删除。

1. 捕获的表列；默认为全列，可以使用@captured_column_list指定需要捕获的列的列表；
2. change table所在的文件组；默认，change table放在数据库的默认文件组中。可以使用@filegroup_name参数指定文件组，但指定的文件组必须已经存在。建议change table放到与原表不同的文件组中。

1. 控制访问change table的角色；可以是一个存在的服务角色或数据库角色，如果指定的角色不存在，则会自动创建数据库角色。sysadmin或db_owner的用户可以访问change table，其他用户必须具有原表所有列的select权限才可以访问change table。另外，如果指定了角色，那么肥sysadmin或db_owner的用户，必须为指定角色的一员。

如果不使用指定角色，则可以使用@role_name参数将其指定为NULL。

原表必须有主键或者能够唯一确定行的唯一索引，才可以启用net changes查询。如果使用的是唯一索引，则必须使用@index_name参数指定索引名称。主键列或唯一索引列必须在捕获的列的列表中。

注：如果在启用cdc之前，表中已有主键，则接下来，无法修改该表的主键（改变主键列，删除主键等），除非禁用cdc。

删除了一张表之后，相应的cdc元数据也会被删除。

对原表有查询权限的用户才可以看该表的cdc信息。

对日志的一次扫描中的最大事务数；
控制sp_cdc_scan在读完日志或达到最大扫描次数之后停止（一次触发模式）。或者控制sp_cdc_scan持续运行直到显式的停止（持续模式）。

--查看空扫描的会话：
--检查延迟：即表上事务提交的时间与change table中捕捉到提交事务时间之间的差值。
--延迟仅对活动会话有效，也就是在empty_scan_count列大于零的会话，延迟为0.

CDC中的数据类型限制：

如果在同一数据库中启用了cdc和事务复制，事务日志中的变化会首先发送到分发数据库中，然后再写到cdc表中。如果分发有延迟，那么相应的，写到cdc也会有延迟。

取决于cdc的配置，会有一到两个TVF创建：

查询自上次更新以来的所有变更

查询直到当前的所有变更

在所有变更结果集中添加提交时间

cdc与ct可在同一数据库中并存。

启用cdc的数据库也可以进行镜像。

当log reader agent同时用于事务复制和cdc时，捕捉到的变化会先写入到分发数据库，然后写到change table中，并一起提交。

恢复或附加一个启用cdc的数据库

SQL Server使用如下逻辑，决定一个数据库在恢复或附加之后是否仍保持启用cdc：

• 如果数据库恢复到相同服务器的相同数据库名，那么cdc保持启用；
• 如果数据库恢复到另一个服务器，那么默认cdc会禁用并且相关的元数据会删除；（如果需要保持cdc启用，在恢复时可使用KEEP_CDC选项）
• 如果数据库分离然后附加到相同或不同服务器，cdc保持启用；
• 如果数据库被附加或恢复到非企业版，并使用了KEEP_CDC选项，那么操作会卡住，因为cdc只有在企业版才可以使用。

当使用always on时，为减少主节点的磁盘负载，变更计算列举应在次节点进行。

• 只标记修改的数据，而不记录该数据修改了多少次等信息；
• 修改的最新数据可以从表中查看；
1. 某一行数据是否改变了；
   *行改变及其相关信息，在同一个事务中记录下来；

在使用change tracking之前，必须现在库级别启用它。

可以使用CHANGE_TRACKING_MIN_VALID_VERSION函数来检查两次同步之间的间隔是否太长（即是否有间隔之外的数据已经被清理掉）。

1. 必须设置兼容级别为90或以上。否则调用CHANGETABLE函数会报错；
2. 使用快照隔离（snapshot isolation）是比对change tracking信息是否一致的最简单方式，所以建议开启快照隔离；

• 对于表的select权限（至少对主键）；

DML更改的每个行，都会记录到change tracking内部表中。对DML操作相关的影响有多方面，例如：

1. 用户表中被改变的行的条数；

如果配置了快照隔离，对DML也会有影响。

1. 内部事务表：整库一个事务表；每个提交事务，都记录一条信息到事务表中。

使用change tracking，需要可以获取数据的变化，然后将变化应用的另一个数据库中，然后更新源端数据库。

每个更改行都有其对应的版本号。

--确认所有表的可用版本号

列级跟踪允许仅跟踪某一列发生的变化。

change tracking相关信息存储在内存中。每个检查点时，会将相关信息刷新到相关的磁盘的内部表上。同时清空内存。

每个启用change tracking的表都会有一个对应的磁盘上的内部表。也会有清理任务，清理磁盘上的内部表中的数据。

版权声明：本文为博主原创文章，遵循 版权协议，转载请附上原文出处链接和本声明。