在stg尝试重现案例

修改datayesdb的CDC的配置值

use dyedb

go

EXEC sys.sp_cdc_stop_job @job_type = 'capture'

EXEC sp_cdc_change_job @job_type='capture', @maxtrans = 50, @maxscans = 1, @continuous = 1, @pollinginterval = 5

EXEC sys.sp_cdc_start_job @job_type = 'capture'

修改完成后可执行以下语句验证

SELECT db_name(database_id),* FROM msdb.dbo.cdc_jobs where database_id in (5,15)

大致结果如下

根据官方白皮书给出的推算公式

(maxtrans * maxscans) / number of seconds between scans

Dyedb当前设置的CDC功能只能提供 50*1 =50的吞吐量，当吞吐量超过该值将造成延时。

复盘环境配置好后通知用户触发脚本来大量修改dyedb里开启cdc的表，尽量模拟insert后直接update的场景。

当吞吐量增加超过50后发现延迟。

use dyedb

go

SELECT latency,command_count/duration AS [Throughput] FROM sys.dm_cdc_log_scan_sessions WHERE session_id = 0

latency Throughput

122896  61

同时我们来对比datayesdb下的cdc状态 （按照官方的计算公式，datayesdb的最大吞吐量在5000，当超过5000时开始有延时）

use datayesdb

go

SELECT latency,command_count/duration AS [Throughput] FROM sys.dm_cdc_log_scan_sessions WHERE session_id = 0

latency     Throughput

63     5796

官方提供了DM sys.dm_cdc_errors用来实时查看cdc的error但用处不大，不如直接监控并发的吞吐量来的直接。所以目前监控的思路还是用监控并发的吞吐量来做。

请注意： 按照官方文档，目前72环境下的cdc支持5000*100的并发量。另外官方并不推用在insert后直接update的环境下。所以如果有有计划的大量数据的增改，或者业务临时需要insert后直接update的操作请预先通知DBA调整该参数，以防止再次发生CDC的延迟。

参考文档：https://msdn.microsoft.com/en-us/library/dd266396.aspx

https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/administer-and-monitor-change-data-capture-sql-server#Capture