你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用 Azure SQL 数据库变更数据捕获 (CDC)

  • 项目

适用于：Azure SQL 数据库

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

概述

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

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

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

数据流

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

Diagram of a flow chart that depicts data flow for change data capture.

先决条件

权限

需要具有 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，请使用 Azure Data Studio 或 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 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 (Transact-SQL)。

提示

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

为 Azure SQL 数据库禁用 CDC

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

注意

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

在数据库级别禁用 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 数据库计算大小的详细信息，请参阅服务层级。

  • 在 Azure SQL 数据库上启用 CDC 后，请考虑扩展 vCores 的数量或过渡到更高的数据库层（如超大规模），以保持以前的性能水平。 有关详细信息，请参阅vCore 购买模型 - Azure SQL 数据库和超大规模服务层级。

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

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

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

重要

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

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

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

  • 没有提供规定何时将更改填充到更改表中的服务级别协议 (SLA)。 也不支持亚秒级延迟。

已知问题和限制

主动日志截断

在 Azure SQL 数据库上启用变更数据捕获 (CDC) 时，加速数据库恢复 (ADR) 的主动日志截断功能将禁用。 这是因为 CDC 扫描访问数据库事务日志。 活动事务将防止日志截断，直到事务提交并且 CDC 扫描跟上进度，或事务中止。 这可能会导致事务日志填充比平时更多的内容，因此应对其进行监视以防止事务日志被填满。

在启用 CDC 时，建议使用“可恢复索引”选项来创建或重新生成索引。 可恢复索引不能将长时间运行的事务一直处于打开状态，允许在此操作期间执行日志截断，以提升日志空间管理效果。 有关详细信息，请参阅联机索引操作指南 - 可恢复索引注意事项。

Azure SQL 数据库服务层级

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

Azure SQL 数据库日志限制 - 弹性池

加速数据库恢复和 CDC 在 Azure SQL 数据库中不兼容。 这是因为 CDC 扫描会主动访问数据库事务日志并与之交互，这可能会与加速数据库恢复 (ADR) 主动截断日志的行为相冲突。

为防止出现可伸缩性和空间管理问题，请密切监视 Azure SQL 数据库，并考虑缩放到更高的数据库层，并允许事务日志根据工作负载需求而增长。

提示

如果工作负载因较高的事务日志吞吐量和较快的事务提交时间（无论数据量如何）而需要更高的整体性能，建议使用超大规模服务层级。

捕获和清理自定义

无法在 Azure SQL 数据库中配置 CDC 的捕获和清理过程的频率。 计划程序自动运行捕获和清理。

Azure SQL 数据库中的故障转移

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

Microsoft Entra ID

注意

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

如果将 Azure SQL 数据库中的数据库创建为 Microsoft Entra 用户并为其启用 CDC，SQL 用户（例如，sysadmin 角色 中的其中一个）将无法禁用/更改 CDC 项目。 但是，另一个 Microsoft Entra 用户将能够在同一数据库上启用/禁用 CDC。

同样，如果以 SQL 用户身份创建 Azure 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)

如果以 SQL 用户身份在 Azure SQL 数据库上启用了变更数据捕获 (CDC) ，则时间点还原 (PITR) 也将 CDC 保留在还原的数据库中，除非它还原到 subcore SLO。 如果还原到 subcore SLO，CDC 项目不可用。

如果你以 Microsoft Entra 用户身份在数据库上启用 CDC，则无法将时间点还原 (PITR) 到 subcore 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 - 弹性池已达到其存储限制。

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

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

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

重要

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

CDC 限制

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

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

  • 建议：在对列大小进行任何更改之前，你必须评估更改是否与 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 (Transact-SQL)。

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

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

  • 建议：建议的步骤是暂停表中的 DML 处理，运行捕获作业来处理更改，为表运行 DDL，运行捕获作业以处理 DDL 更改，然后重新启用 DML 处理。 有关详细信息，请参阅在处理更改时 CDC 捕获作业失败。

创建用户和分配角色

如果已删除 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';

相关内容