Cdc。<>capture_instance_CT (Transact-SQL)

适用于:SQL ServerAzure SQL 数据库Azure SQL 托管实例

在源表上启用变更数据捕获时创建的更改表。 该表为对源表执行的每个插入和删除操作返回一行,为对源表执行的每个更新操作返回两行。 如果启用源表时未指定更改表的名称,则会派生该名称。 名称的格式为 cdc。capture_instance_CT其中 capture_instance 是源表的架构名称和 schema_table格式的源表名称。 例如,如果 AdventureWorks 示例数据库中的表 Person.Address 启用了变更数据捕获,则派生的更改表名称将cdc.Person_Address_CT

建议 不要直接查询系统表。 请改为执行 cdc.fn_cdc_get_all_changes_<capture_instance>cdc.fn_cdc_get_net_changes_<capture_instance> 函数。

列名称 数据类型 说明
__$start_lsn binary(10) 与相应更改的提交事务关联的日志序列号 (LSN)。

在同一事务中提交的所有更改将共享同一个提交 LSN。 例如,如果对源表的删除操作删除了两行,则更改表将包含两行,每个行具有相同的 __$start_lsn 值。
__$end_lsn binary(10) 标识为仅供参考。 不支持。 不保证以后的兼容性。

在 SQL Server 2012 (11.x) 中,此列始终为 NULL。
__$seqval binary(10) 事务日志中表示的操作序列。 不应用于排序。 请改用 __$command_id 列。
__$operation int 标识与相应更改关联的数据操作语言 (DML) 操作。 可以是以下值之一:

1 = 删除

2 = 插入

3 = 更新(旧值)

列数据中具有执行更新语句之前的行值。

4 = 更新(新值)

列数据中具有执行更新语句之后的行值。
__$update_mask varbinary(128) 基于更改表的列序号的位掩码,用于标识那些发生更改的列。
<捕获的源表列> 多种多样 更改表中的其余列是在创建捕获实例时源表中标识为已捕获列的那些列。 如果已捕获列的列表中未指定任何列,则源表中的所有列将包括在此表中。
__$command_id int 跟踪事务中的操作顺序。

备注

__$command_id 是在版本 2012 到 2016 的累积更新中引入的。 有关版本和下载信息,请参阅知识库文章3030352:为 Microsoft SQL Server 数据库启用变更数据捕获后,更新行的更改表排序不正确。 有关详细信息,请参阅 CDC 功能在升级到 SQL Server 2012、2014 和 2016 的最新 CU 后可能会中断

已捕获列的数据类型

此表中包含的已捕获列具有与其对应源列相同的数据类型和值,但下述情况例外:

  • 时间戳 列定义为 二进制 (8)

  • 标识 列定义为 intbigint

不过,这些列中的值与源列的值相同。

大型对象数据类型

当 __$operation = 1 或 __$operation = 3 时,始终为数据类型 imagetextntext 的列分配 NULL 值。 当 __$operation = 3 时,数据类型 为 varbinary (max) varchar (max) nvarchar (max) 的列分配 NULL 值,除非列在更新期间发生更改。 当 __$operation = 1 时,将为这些列指定删除时的值。 捕获实例中包含的计算列始终具有 NULL 值。

默认情况下,在一个 INSERT、UPDATE、WRITETEXT 或 UPDATETEXT 语句中可添加到已捕获列的最大大小为 65,536 字节或 64 KB。 若要增加此大小以支持更大的 LOB 数据,请使用 配置最大文本 repl 大小服务器配置选项 指定更大的最大大小。 有关详细信息,请参阅 配置 max text repl size 服务器配置选项

数据定义语言修改

对源表的 DDL 修改(例如添加或删除列)记录在 cdc.ddl_history 表中。 这些更改不会应用于更改表。 也就是说,更改表的定义保持不变。 将行插入更改表时,捕获过程将忽略与源表关联的捕获列列表中未显示的那些列。 如果某列出现在已捕获列的列表中,但已不再位于源表中,则会为该列指定一个 null 值。

更改源表中列的数据类型也会记录在 cdc.ddl_history 表中。 但是,此更改不会改变更改表的定义。 当捕获进程遇到对源表所做的 DDL 更改的此日志记录时,更改表中的此已捕获列的数据类型会进行相应更改。

如果需要修改源表中已捕获列的数据类型以减小该数据类型的大小,请使用以下过程以确保可以成功修改更改表中的对应列。

  1. 在源表中,更新要修改的列中的值以适合所计划的数据类型大小。 例如,如果将数据类型从 int 更改为 smallint,请将值更新为适合 smallint 范围的大小,即 -32,768 到 32,767。

  2. 在更改表中,对对应列执行相同的更新操作。

  3. 通过指定新数据类型来更改源表。 该数据类型更改成功传播到更改表。

数据操作语言修改

对启用了变更数据捕获的源表执行插入、更新和删除操作时,这些 DML 操作的记录将显示在数据库事务日志中。 变更数据捕获过程从事务日志中检索有关这些更改的信息,并将一行或两行添加到更改表以记录更改。 条目将按照提交到源表的顺序添加到更改表中。 也就是说,通常必须对一组更改执行更改表条目的提交,而不是按每个条目执行。

插入操作导致将一行添加到更改表中;删除操作导致向更改表添加一行;如果SQL Server将更新实现为“延迟更新”,这意味着作为一对删除和插入操作,则更新操作会导致向更改表添加两行:第一行反映已捕获数据的删除,第二行反映插入已更新的捕获数据;如果SQL Server 不将更新实现为“延迟更新”,更新操作会导致向更改表添加两行:第一行反映更新前捕获的数据,第二行反映更新后捕获的数据。

在更改表条目中, __$start_lsn 列用于记录与源表的更改关联的提交 LSN, __$command_id 列用于对其事务中的更改进行排序, __$operation 列用于记录执行的操作。 这些元数据列可共同用于确保保留源更改的提交顺序。 由于捕获进程从事务日志中获取其更改信息,因此请务必注意,更改表条目不会与其对应的源表更改同步显示。 在捕获进程处理了事务日志中的相关更改条目后,对应的更改将异步显示。

对于插入和删除操作,会设置更新掩码中的所有位。 对于更新操作,会修改更新(旧值)行和更新(新值)行中的更新掩码以指出在更新过程中有所更改的列。

另请参阅

sys.sp_cdc_enable_table (Transact-SQL)
sys.sp_cdc_get_ddl_history (Transact-SQL)