SQL Server CDC捕获作业自动停止问题排查与解决请求

这问题我之前在Linux容器部署的SQL Server环境里碰到过类似的，咱们一步步来排查和解决：

先从最容易验证的点入手 #

1. 检查跟踪表的用户自定义触发器 #

CDC捕获作业的嵌套错误，大概率是用户触发器和CDC的系统逻辑产生了递归调用。比如你的MyTrackedTable上有触发器，在数据变更时又修改了同一张表或者其他CDC跟踪的表，导致CDC捕获进程反复触发。

先查询表上的触发器状态：

SELECT name, is_disabled 
FROM sys.triggers 
WHERE parent_id = OBJECT_ID('dbo.MyTrackedTable');

如果有启用的用户触发器，先临时禁用它，然后重启CDC捕获作业，观察10分钟以上看是否还会停止。如果问题消失，那就是触发器的逻辑和CDC冲突了，需要修改触发器避免递归（比如加IF TRIGGER_NESTLEVEL() > 1 RETURN;这类判断）。

2. 调整CDC捕获作业的参数 #

你当前的作业配置@maxtrans=500、@pollinginterval=1，意味着作业每秒扫描一次，每次最多处理500个事务。在Linux容器环境下，可能因为IO或者调度的差异，短时间内处理大量事务触发了内部嵌套。

试试调小单次处理的事务数，延长轮询间隔：

EXEC sys.sp_cdc_change_job 
    @job_type = N'capture', 
    @maxtrans = 100, 
    @pollinginterval = 5;
GO
EXEC msdb.dbo.sp_stop_job N'cdc.MyDbName_capture';
EXEC msdb.dbo.sp_start_job N'cdc.MyDbName_capture';

观察作业是否还会出现停止的情况。

进一步排查深层原因 #

3. 检查SQL Server版本与补丁 #

官方Docker镜像如果是基础版本，可能存在Linux环境下CDC的已知bug，比如某些早期CU版本处理批量变更或大事务时会触发嵌套层级超限。建议升级到对应版本的最新CU镜像，比如如果你用的是2022版本，换成mcr.microsoft.com/mssql/server:2022-latest（这个镜像会自动拉取最新的CU）。

4. 用Extended Events跟踪错误触发点 #

如果前面的方法没解决，需要精准定位是哪条语句导致的嵌套错误。可以创建一个Extended Events会话来捕获错误详情：

CREATE EVENT SESSION [CDC_Nesting_Error] ON SERVER 
ADD EVENT sqlserver.error_reported(
    ACTION(sqlserver.sql_text,sqlserver.session_id)
    WHERE ([error_number]=(217))
)
ADD TARGET package0.event_file(SET filename=N'CDC_Nesting_Error.xel')
WITH (STARTUP_STATE=OFF);
GO
-- 启动会话
ALTER EVENT SESSION [CDC_Nesting_Error] ON SERVER STATE=START;

等作业再次报错停止后，停止会话并查看事件文件：

ALTER EVENT SESSION [CDC_Nesting_Error] ON SERVER STATE=STOP;
GO
SELECT 
    event_data.value('(event/@timestamp)[1]', 'datetime2') AS [Time],
    event_data.value('(event/data[@name=''error_number'']/value)[1]', 'int') AS ErrorNumber,
    event_data.value('(event/data[@name=''message'']/value)[1]', 'nvarchar(MAX)') AS ErrorMessage,
    event_data.value('(event/action[@name=''sql_text'']/value)[1]', 'nvarchar(MAX)') AS SQLText
FROM 
    (SELECT CAST(event_data AS XML) AS event_data
     FROM sys.fn_xe_file_target_read_file('CDC_Nesting_Error*.xel', NULL, NULL, NULL)) AS x;

通过捕获到的SQLText就能知道是哪个存储过程或语句触发了嵌套，针对性修复。

5. 重置CDC配置 #

如果怀疑CDC元数据损坏，可以先禁用再重新启用该表的CDC：

-- 禁用表的CDC
EXEC sys.sp_cdc_disable_table 
    @source_schema = N'dbo', 
    @source_name = N'MyTrackedTable', 
    @capture_instance = N'dbo_MyTrackedTable';
GO
-- 重新启用表的CDC
EXEC sys.sp_cdc_enable_table 
    @source_schema = N'dbo', 
    @source_name = N'MyTrackedTable', 
    @role_name = NULL;
GO
-- 重启捕获作业
EXEC msdb.dbo.sp_stop_job N'cdc.MyDbName_capture';
EXEC msdb.dbo.sp_start_job N'cdc.MyDbName_capture';

注意：这会清空现有的变更表数据，如果需要保留历史数据，先备份cdc.dbo_MyTrackedTable_CT再操作。

最后补充 #

你提到关闭RECURSIVE_TRIGGERS没用，是因为这个设置只影响用户自定义触发器的递归，CDC的内部逻辑是系统级的，不受这个参数控制。所以重点还是放在用户触发器、作业参数和版本补丁上。

内容的提问来源于stack exchange，提问作者Neo.Mxn0