在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
