Azure SQL 数据库中的变更数据捕获 (CDC)

适用于：Azure SQL 数据库

• Azure SQL 数据库
• Azure SQL 托管实例
• SQL Server

本文介绍如何在 Azure SQL 数据库中实现变更数据捕获 (CDC)，以在修改表和行时记录数据库上的活动。 有关 CDC 功能的详细信息（包括如何在 SQL Server 和 Azure SQL 托管实例中实现此功能），请参阅 什么是变更数据捕获（CDC）？

概述

在 Azure SQL 数据库中，更改数据捕获计划程序取代了用于捕获和清理源表更改数据的 SQL Server 代理 作业。 计划程序在数据库中自动运行捕获和清理，无需任何外部依赖项即可保证可靠性或高性能。 用户保留可根据需要手动启动捕获和清理过程的选项。

此技术使用的数据使用者的一个典型示例是提取、转换和加载 (ETL) 应用程序。 ETL 应用程序以增量方式将 SQL Server 源表中的更改数据加载到数据仓库或数据市场。 虽然数据仓库中的源表的表示形式必须反映源表中的更改，但刷新源副本的端到端技术并不适用。 相反，你需要一种具有特定结构的可靠更改数据流，以便使用者可以将其应用于不同的目标数据表示形式。 SQL Server 变更数据捕获提供了此技术。

要详细了解 Azure SQL 数据库中的变更数据捕获，还可以观看此“公开的数据”剧集：

数据流

下图说明了使用 Azure SQL 数据库的变更数据捕获的主体数据流。

先决条件

权限

需要具有 db_owner 角色才能为 Azure SQL 数据库启用变更数据捕获。

Azure SQL 数据库计算要求

对于单一数据库和弹性池，您都可以在基于 vCore 的购买模型下的任何服务层级中启用 Azure SQL 数据库的 CDC。

对于 DTU 购买模型中的数据库，只有处于 S3 层级或更高层级的数据库才支持 CDC。 CDC 不支持 Subcore 层级（基本、S0、S1、S2）。

为 Azure SQL 数据库启用 CDC。

你必须先为 Azure SQL 启用 CDC，然后才能为各个表创建捕获实例。

若要启用 CDC，请通过 SQL Server Management Studio（SSMS）连接到 Azure SQL 数据库。 打开新的查询窗口，然后通过运行以下 T-SQL 启用 CDC：

EXEC sys.sp_cdc_enable_db;
GO

注意

若要确定数据库是否已启用此功能，请在 is_cdc_enabled 目录视图中查询 sys.databases 列。

当对数据库启用了变更数据捕获之后，将为数据库创建 cdc schema、cdc user、元数据表和其他系统对象。 cdc schema 包含这些变更数据捕获元数据表，并且在为源表启用 cdc 后，各个变更表用作变更数据的存储库。 cdc schema 还包含用于查询更改数据的关联系统函数。

重要

变更数据捕获要求独占使用 cdc schema 和 cdc user。 如果某数据库中当前存在名为 cdc 的架构或数据库用户，那么在删除或重命名此架构或用户之前，不能对此数据库启用 CDC。

为数据表启用 CDC

为 Azure SQL 数据库启用 CDC 后，可以在表级别启用 CDC，方法是选择一个或多个表来跟踪数据变更。 可以通过使用存储过程 sys.sp_cdc_enable_table 为各个源表创建捕获实例。

若要为表启用 CDC，请运行以下 T-SQL：

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL;
GO

提示

前面的示例没有使用显式 @role_name 将参数设置为 NULL，但可以使用一个控制角色来限制对变更数据的访问。

要采集的源表列

默认情况下，源表中的所有列都将标识为已捕获列。 如果只需要跟踪这些列中的部分列（如出于保密或性能方面的原因），请使用 @captured_column_list 参数指定这些列中要跟踪的部分列。

若要为表中的特定列列表启用 CDC，请运行以下 T-SQL：

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL,
    @captured_column_list = N'Column1, Column2, Column3';
GO

提示

注意，前面的示例没有使用显式 @role_name 将参数设置为 NULL，但可以使用一个控制角色来限制对变更数据的访问。

用于控制对更改表的访问的角色

指定角色的目的是控制对更改数据的访问。 指定的角色可以为现有的固定服务器角色或数据库角色。 如果指定的角色不存在，则会自动创建该名称的数据库角色。 用户必须对源表中的所有捕获列拥有 SELECT 权限。 此外，当指定角色时，不是 sysadmin 或 db_owner 角色成员的用户还必须是指定角色的成员。

若要为指定控制角色的表启用 CDC，请运行以下 T-SQL：

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = N'RoleName'
GO

如果不想使用访问控制角色，请将 @role_name 参数显式设置为 NULL。

用于查询净更改的函数

捕获实例将始终包含一个表值函数以返回在指定的时间间隔内出现的所有更改表项。 此函数通过在 cdc.fn_cdc_get_all_changes_ 后追加捕获实例名称来命名。 有关详细信息，请参阅 cdc.fn_cdc_get_all_changes。

如果参数 @supports_net_changes 设置为 1，则还会为捕获实例生成一个净变化函数。 对于在调用中指定的时间间隔内每个发生更改的不同数据行，此函数仅返回一项更改记录。 有关详细信息，请参阅 cdc.fn_cdc_get_net_changes。

若要支持净更改查询，源表必须具有用于唯一标识行的主键或唯一索引。 如果使用了唯一索引，则必须使用 @index_name 参数指定索引名称。 在主键或唯一索引中定义的列必须包含在要捕获的源列列表中。

若要为支持净更改的表启用 CDC，请运行以下 T-SQL：

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL,
    @supports_net_changes = 1
GO

如果对具有现有主键的表启用变更数据捕获，且未使用 @index_name 参数来标识备用的唯一索引，则变更数据捕获功能将使用主键。 如果不先禁用该表的变更数据捕获功能，则不允许对主键进行后续修改。 无论在配置更改数据捕获时是否请求对净更改查询的支持，情况都是如此。

如果为变更数据捕获启用表时该表中没有主键，则变更数据捕获将忽略后来添加的主键。 由于变更数据捕获不会使用在启用表之后创建的主键，因此可以不受限制地将该键及键列删除。

有关 sys.sp_cdc_enable_table 存储过程参数的详细信息，请参阅 sys.sp_cdc_enable_table。

提示

若要确定是否已对某个源表已启用了变更数据捕获，请在 is_tracked_by_cdc 目录视图中检查 sys.tables 列。

为 Azure SQL 数据库禁用 CDC

禁用 Azure SQL 数据库的 CDC 会移除所有相关的变更数据捕获元数据，包括 cdc user、cdc schema 以及外部计划程序的捕获和清理进程。 但是，任何由变更数据捕获创建的访问控制角色不会被自动删除，而是必须将其显式删除。

注意

若要确定是否已对数据库启用 CDC，请在 is_cdc_enabled 目录视图中查询 sys.databases 列。

在数据库级别禁用 CDC 之前，无需先为各个单独的表禁用 CDC。

若要在数据库级别禁用 CDC，请运行以下 T-SQL：

EXEC sys.sp_cdc_disable_db;
GO

提示

在数据库级别禁用 CDC 后，如果要再次使用 CDC 功能，则需要再次为各个表启用 CDC。

管理 CDC

在 Azure SQL 数据库中，CDC 是跟踪和管理数据库表中更改的关键功能。 与传统的 SQL Server 环境不同，Azure SQL 数据库使用变更数据捕获计划程序来处理 CDC 任务，而不是依赖于 SQL Server 代理作业。 此计划程序会自动为数据库中的 CDC 表启动定期捕获和清理过程，无需任何外部依赖项即可保证可靠性或高性能。

自动CDC捕获和清除

Azure SQL 数据库中的 CDC 捕获作业无缝运行，每 20 秒运行一次，可高效跟踪更改。 同时，清理作业每小时运行一次，确保 CDC 表始终保持在优化状态。 用户可以放心，CDC 管理在无需手动干预的情况下自动进行。

重要

如果无服务器数据库已启用 CDC 并且处于暂停状态，则 CDC 不运行。 CDC SCAN 不会影响自动暂停功能。

CDC 手动控制

虽然 CDC 自动运行，但用户可自由选择按需执行手动 CDC 操作。 通过 sp_cdc_scan和 sp_cdc_cleanup_change_tables 过程，可以根据需要触发捕获和清理任务。

监控 CDC

Azure SQL 数据库提供了用于监视 CDC 活动的有效工具。 两个动态管理视图（sys.dm_cdc_log_scan_sessions 和 sys.dm_cdc_errors）帮助深入了解 CDC 流程，确保用户充分了解数据更改。

CDC 自定义

虽然 Azure SQL 数据库简化了 CDC 管理，但仍存在一些限制：

• 无法自定义 CDC 捕获和清理作业的频率。
• Azure SQL 数据库中不使用 pollinginterval 和 continuous 值来捕获和清理作业。
• 从 cdc.cdc_jobs 表中删除捕获作业条目不会停止后台捕获作业。
• 删除清理作业条目将停止清理作业。
• cdc.cdc_jobs 表存在于 cdc 架构中，而不是 msdb。

尽管存在这些限制，但仍可以自定义以下选项：

• 查询 cdc.cdc_jobs 表以获取当前配置详情。
• 使用 sp_cdc_change_job 存储过程调整 maxtrans 和 maxscans 选项。
• 根据需要使用 sp_cdc_drop_job 和 sp_cdc_add_job 来管理作业。

性能注意事项和建议

为 Azure SQL 数据库启用变更数据捕获产生的性能影响类似于为 SQL Server 或 Azure SQL 托管实例启用 CDC 产生的性能影响。 但是，启用 CDC 时，有几个因素会影响性能影响，包括：

• Azure SQL 数据库中已启用 CDC 的表数量。

• 被跟踪的表中的更改频率，或事务量。 活动事务会防止日志截断，直到事务提交并且 CDC 扫描跟上进度，或事务中止。 这可能会导致事务日志填充比平时更多的内容，因此应对其进行监视以防止事务日志被填满。

• 确保源数据库中有可用空间，因为 CDC 项目（例如，CT 表、cdc_jobs 等）存储在同一数据库中

• 无论您使用的是单个数据库，还是属于弹性池。

• 弹性池中的数据库共享池中的资源（如磁盘空间），因此在多个数据库上启用 CDC 存在达到弹性池磁盘大小的最大大小的风险。 监视 CPU、内存和日志吞吐量等资源。 有关详细信息，请参阅密集弹性池中的资源管理。

• 在处理弹性池中的数据库时，必须考虑到启用了 CDC 的表的数量，和这些表所属的数据库的数量。 我们建议评估工作负载，并采取必要措施，例如扩展弹性池。 有关详细信息，请参阅在 Azure SQL 数据库中缩放弹性池资源。

重要

这些注意事项属于一般指南。 有关优化特定工作负荷性能的精确指南，请联系 Microsoft 支持部门。

将 CDC 与 Azure SQL 数据库配合使用时，请考虑以下最佳做法：

• 在生产环境中的数据库上启用 CDC 之前，请彻底测试您的工作负载，以帮助确定适合您的工作负载的 SLO。 有关 Azure SQL 数据库计算大小的详细信息，请参阅服务层级。

• 考虑缩放 vCore 数或转换为更高数据库层（例如“超大规模”），以便在 Azure SQL 数据库上启用 CDC 后保持以前的性能级别。 有关详细信息，请参阅vCore 购买模型 - Azure SQL 数据库和超大规模服务层级。

• 密切监视空间利用率。 有关详细信息，请参阅管理 Azure SQL 数据库中数据库的文件空间。

• 监视日志生成率，有关详细信息，请参阅用户工作负荷和内部进程的资源消耗量。

• CDC 扫描和清理过程属于常规数据库工作负载（也称消耗资源）的一部分。 视事务量大小而定，由于扫描和清理过程无法跟上负载，性能下降可能会非常明显，因为整行数据都会被添加到变更表中，而对于更新操作，还会包含更新前镜像。 我们建议评估工作负载，并根据前面的建议采取必要措施。 有关详细信息，请参阅本文中的 CDC 管理部分。

重要

调度程序在 SQL 数据库中自动执行捕获和清理操作。 CDC 捕获作业每 20 秒运行一次，清理作业每小时运行一次。

• 为了防止延迟增加，请确保启用 CDC 的数据库的数量不超过分配给弹性池的 vCore 的数量。 有关详细信息，请参阅密集弹性池中的资源管理。

• 根据工作负载和性能级别，请考虑将 CDC 保留期更改为小于默认值 3 天，以确保清理过程可以跟上更改表中的更改。 在监视数据库大小的同时保持较短的保留期是一种很好的做法。

• 对于何时将更改填充到更改表中，不提供服务级别协议 (SLA)。 也不支持亚秒级延迟。

已知问题和限制

新增列的默认约束

在表上启用 CDC 并且添加了具有默认约束的不可为 null 列时，现有行数据将具有默认约束的值。 但是，CDC 将对NULL使用，而不是默认值。 这仅适用于应用 DDL 之前存在的数据。 解决方法是，对现有行发出非更改 UPDATE 语句，或者对表的聚集索引进行 ALTER INDEX ... REBUILD 操作。 如果没有聚集索引，则对堆使用 ALTER TABLE ... REBUILD 。

主动日志截断

在 Azure SQL 数据库中启用更改数据捕获（CDC）时，将禁用加速数据库恢复（ADR）的主动日志截断功能。 这是因为 CDC 扫描访问数据库事务日志。 活动事务将防止日志截断，直到事务提交并且 CDC 扫描跟上进度，或事务中止。

Azure SQL 数据库服务层级

虽然基于 vCore 的购买模型中任何服务层级中的数据库和弹性池都支持 CDC，但 DTU 购买模型不支持低于 S3 的数据库（例如基本、S0、S1、S2）。

Azure SQL 数据库日志限制

加速数据库恢复和 CDC 兼容。 但是，启用 CDC 时，将禁用 ADR 的主动日志截断行为。 这是因为 CDC 扫描会主动访问数据库事务日志并与之交互，从而阻止 ADR 的主动日志截断行为。

启用 CDC 时，可能会观察到更高的事务日志利用率。 可能需要纵向扩展到更高的服务层级或计算规格，以确保有足够的事务日志空间满足所有负载的需求。

提示

如果您的工作负载因需要更高的事务日志吞吐量和更快的事务提交时间而要求更高的整体性能，请使用Hyperscale 服务层。

在线操作

不支持联机索引操作

启用数据库更改数据捕获时，不支持联机索引操作。 您可能会遇到错误 18773：“在构造命令期间，找不到列“%.*ls”的文本信息记录，ID 为 %d。”

捕获和清理自定义设置

无法在 Azure SQL 数据库中配置 CDC 的捕获和清理过程的频率。 调度程序会自动执行捕获和清理。

Azure SQL 数据库中的故障转移

在本地或 GeoDR 故障转移方案中，如果数据库启用了 CDC，则故障转移发生后，捕获和清理数据更改的过程会自动发生在新的主数据库上。

Microsoft Entra ID

注意

Microsoft Entra ID 以前称为 Azure Active Directory (Azure AD)。

如果你以 Microsoft Entra 用户身份在 Azure SQL 数据库 中创建数据库并为其启用 CDC，SQL 用户（例如，即使是属于 sysadmin 角色的用户）也无法禁用或更改 CDC 对象。 但是，另一个 Microsoft Entra 用户将能够在同一数据库上启用/禁用 CDC。

同样，如果数据库是以 SQL 用户身份创建的，则无法以 Microsoft Entra 用户身份启用或禁用更改数据捕获。

如果以 Microsoft Entra 用户身份在 Azure SQL 数据库中创建数据库，则无法启用 CDC，然后不要启用 CDC，在还原数据库后再尝试启用 CDC。

若要解决此问题，请使用 Microsoft Entra 管理员帐户连接到数据库，并运行以下 T-SQL：

ALTER AUTHORIZATION ON DATABASE::[<restored_db_name>] TO [<azuread_admin_login_name>];

EXEC sys.sp_cdc_enable_db;

时间点还原 (PITR)

如果已在 Azure SQL 数据库中以 SQL 用户身份启用 CDC，那么时间点还原 (PITR) 将在还原的数据库中保留 CDC，除非它被还原到 subcore SLO。 如果还原到 subcore SLO，则 CDC 项目将不可用。

如果你以 Microsoft Entra 用户身份对数据库启用 CDC，则无法执行时间点还原 (PITR) 到子核心 SLO。 将数据库还原到与源相同或更高的 SLO，然后在必要时禁用 CDC。

故障排除

本部分提供有关 Azure SQL 数据库中的 CDC 的指导信息和疑难解答步骤。 与 CDC 相关的错误可能会阻碍捕获过程的正常运行，并导致数据库事务日志的扩展。

要检查这些错误，你可以查询动态管理视图 sys.dm_cdc_errors。 如果 sys.dm_cdc_errors 动态管理视图返回任何错误，请参阅以下部分，了解缓解步骤。

注意

有关特定错误代码的详细信息，请参阅数据库引擎事件和错误。

以下是本部分中包含的不同疑难解答类别：

类别	说明
已修改的元数据	包括有关如何在修改或删除跟踪表时缓解与 CDC 相关的问题的信息。
数据库空间管理	包括有关如何在数据库空间用完时缓解问题的信息。
CDC 限制条件	包括有关如何缓解 CDC 限制导致的问题的信息。

已修改的元数据

错误 200/208 - 对象名称无效。

• 原因：在删除 CDC 元数据后，可能会出现此错误。 要使 CDC 正常运行，不应手动修改任何 CDC 元数据，如 CDC schema、更改表、CDC 系统存储过程、默认 cdc user 用户权限 (sys.database_principals) 或重命名 cdc user。

• 建议：要解决此问题，需要为数据库禁用并重新启用 CDC。 当为某个数据库启用变更数据捕获时，将为该数据库创建 cdc 架构、cdc 用户、元数据表和其他系统对象。 为数据库启用 CDC 后，需要为各个表手动重新启用 CDC。

注意

不应更改或删除在 sys.objects 系统目录视图中找到的具有 is_ms_shipped=1 和 schema_name=cdc 的对象。

错误 1202 - 数据库主体不存在，或者用户不是成员

• 原因：在删除 CDC 用户后，可能会出现此错误。 要使 CDC 正常运行，不应手动修改任何 CDC 元数据，如 CDC schema、更改表、CDC 系统存储过程、默认 cdc user 用户权限 (sys.database_principals) 或重命名 cdc user。

• 建议：确保数据库中存在 cdc 用户，并且分配了 db_owner 角色。 要创建 cdc 用户，请参阅示例创建 cdc 用户并分配角色。

错误 15517 - 无法作为数据库主体执行，因为主体不存在。

• 原因：无法模拟此类主体的身份，或者你没有相应权限。 在删除 CDC 元数据或其已不再属于 db_owner 角色时，可能会出现此错误。 要使 CDC 正常运行，不应手动修改任何 CDC 元数据，如 CDC schema、更改表、CDC 系统存储过程、默认 cdc user 用户权限 (sys.database_principals) 或重命名 cdc user。

• 建议：确保数据库中存在 cdc 用户，并且分配了 db_owner 角色。 要创建 cdc 用户，请参阅示例创建 cdc 用户并分配角色。

错误 18807 - 找不到复制系统表的对象 ID。

• 导致：当 SQL Server 数据库引擎找不到或访问复制系统表“%s.”时，会发生此错误。 该表可能缺失或无法访问。 若要使 CDC 正常运行，请不要手动修改任何 CDC 元数据，例如 CDC schema、更改表、CDC 系统存储过程、默认 cdc user 权限（sys.database_principals）或重命名 cdc user。

• 建议：请验证该系统表是否存在，以及是否可以通过直接查询表进行访问。 查询 sys.objects 系统目录，使用 is_ms_shipped=1 和 schema_name=cdc 将谓词子句设置为列出所有与 CDC 相关的对象。 如果查询未返回任何对象，则应禁用并重新为数据库启用 CDC。 为某个数据库启用变更数据捕获，会为该数据库创建 cdc schema、cdc user、元数据表和其他系统对象。 为数据库启用 CDC 后，需要为各个表手动重新启用 CDC。

错误 21050 - 只有 sysadmin 或 db_owner 固定服务器角色的成员才能执行此操作。

• 原因：cdc 用户已从 db_owner 数据库角色或 sysadmin 服务器角色中删除。

• 建议：确保 cdc 用户已分配 db_owner 角色。 要创建 cdc 用户，请参阅示例创建 cdc 用户并分配角色。

数据库空间管理

错误 1105 - 由于文件组已满，无法为数据库中的对象分配空间。

• 原因：当数据库主文件组的空间耗尽，并且 SQL Server 无法为该文件组中的对象（如表或索引）分配更多空间时，会发生此错误。

• 建议：要解决此问题，请删除数据库中任何不必要的数据以释放空间。 确定文件组中可以安全删除的未使用的表、索引或其他对象。 密切监视空间利用率，有关详细信息，请参阅管理 Azure SQL 数据库中数据库的文件空间。

  如果不能删除不必要的数据/对象，请考虑扩展到更高的数据库层。

重要

有关 Azure SQL 数据库（单一数据库）计算大小 (SLO) 的详细信息，请参阅使用 vCore 购买模型的单一数据库的资源限制以及使用 DTU 购买模型的单一数据库的资源限制 - Azure SQL 数据库。

错误 1132 - 弹性池已达到其存储限制。

• 原因：当弹性池中的存储使用量超过已分配的限制时，就会发生此错误。

• 建议：要解决此问题，请实施数据存档和清除策略，从而在作为弹性池一部分的数据库中仅保留必要的数据。 密切监视空间利用率。 有关详细信息，请参阅管理 Azure SQL 数据库中数据库的文件空间。

  如果不能存档数据或删除不必要的数据/对象，请考虑扩展到更高的数据库层。

重要

有关 Azure SQL 数据库（单个数据库）计算大小 (SLO) 的详细信息，请参阅使用 DTU 购买模型的单一数据库的资源限制和使用 DTU 购买模型的弹性池的资源限制。

CDC 限制

错误 2628 — 字符串或二进制数据在表中会被截断

• 原因：使用 DDL 语句修改已启用 CDC 的表的列大小，可能会导致后续的 CDC 捕获过程出现问题。 sys.dm_cdc_errors 动态管理视图 (DMV) 可用于检查任何 CDC 是否存在已报告的问题，例如错误号 2628 和 8115。

• 建议：在对列大小进行任何更改之前，你必须评估更改是否与 CDC 更改表中的现有数据兼容。 要解决此问题，需要为数据库禁用并重新启用 CDC。 有关为数据库或表启用 CDC 的详细信息，请参阅本文中的为 Azure SQL 数据库启用 CDC 和为表启用 CDC 部分。

错误 22830 - 此版本的 SQL Server 不支持模拟上下文中的内置函数“SUSER_SNAME”

• 原因：如果数据库中存在用户触发器，且该触发器包含对 create_table 上的 SUSER_SNAME() 的调用，则在启用 CDC 时会出现此错误。 可以使用以下 Transact-SQL 脚本列出触发器。 此命令提供对象触发器及相应 object_id 的详细信息：

  SELECT name,
      object_id
  FROM sys.triggers
  WHERE parent_class_desc = 'DATABASE'
      AND is_disabled = 0;
  

  获取触发器定义后，即可使用以下脚本查找对 SYSTEM_USER 的调用：

  SELECT OBJECT_DEFINITION(object_id) AS trigger_definition;
  

• 建议：若要解决此问题，请为从前一个脚本中获取的每一个用户触发器执行这些步骤。

  • 禁用触发器
  • 启用 CDC
  • 重新启用触发器

有关详细信息，请参阅 DISABLE TRIGGER。

错误 913 - 在处理具有系统 CLR 数据类型的表的更改时，CDC 捕获作业失败

• 原因：当在具有系统 CLR 数据类型的表上启用 CDC、进行 DML 更改，然后在 CDC 捕获作业处理与其他表相关的更改时对同一表进行 DDL 更改，就会发生此错误。

• 建议：建议的步骤是暂停表中的 DML 处理，运行捕获作业来处理更改，为表运行 DDL，运行捕获作业以处理 DDL 更改，然后重新启用 DML 处理。 更多信息请参见 CDC捕获作业 在处理带有系统CLR数据类型（几何、地理或层次）的表变更时失败。

创建用户和分配角色

如果 cdc user 已被移除，您可以手动将该用户重新添加回来。

使用以下 T-SQL 脚本创建用户 (cdc)，并分配适当的角色 (db_owner)。

IF NOT EXISTS (
    SELECT *
    FROM sys.database_principals
    WHERE NAME = 'cdc'
)
BEGIN
    CREATE USER [cdc] WITHOUT LOGIN
    WITH DEFAULT_SCHEMA = [cdc];
END

EXEC sp_addrolemember 'db_owner', 'cdc';

检查并添加角色成员资格

要验证 cdc 用户是否属于 sysadmin 或 db_owner 角色，请运行以下 T-SQL 查询：

EXECUTE AS USER = 'cdc';

SELECT is_srvrolemember('sysadmin'), is_member('db_owner');

如果 cdc 用户不属于任一角色，请执行以下 T-SQL 查询，以将 db_owner 角色添加到 cdc 用户。

EXEC sp_addrolemember 'db_owner' , 'cdc';

相关内容

• 处理变更数据
• 跟踪数据更改 (SQL Server)
• 管理和监视变更数据捕获
• 临时表