SQL Server 2016 SP3中sys.sp_add_ct_history存储过程无法找到求助

关于sys.sp_add_ct_history的可见性问题 #

• 该存储过程是SQL Server引擎内部专用的隐藏对象，不会在sys.all_objects、sys.procedures等常规系统视图中被查询到，也不支持用户直接执行——这就是你执行EXEC sys.sp_add_ct_history提示“找不到存储过程”的原因。
• 它不属于用户可访问的对象范畴，即使拥有SA级别的权限，也无法通过常规方式查看或调用，仅由SQL Server的变更跟踪清理线程/自动任务内部触发调用。

为什么dbo.MSchange_tracking_history表有记录 #

当SQL Server执行变更跟踪的自动清理操作时，会内部调用sys.sp_add_ct_history来向dbo.MSchange_tracking_history表写入清理历史记录，这个过程完全由引擎主导，无需用户介入。

性能变慢问题的排查方向 #

• 检查变更跟踪配置：查询sys.change_tracking_databases，确认auto_cleanup是否启用，以及retention_period（保留周期）是否设置过短——过于频繁的清理操作可能导致资源占用过高。

  SELECT name, auto_cleanup, retention_period, retention_period_units 
  FROM sys.change_tracking_databases;
  

• 监控MSchange_tracking_history表的负载：如果该表数据量过大，写入时会引发IO竞争或锁等待。可以查看表的大小，考虑手动归档或清理历史数据（注意：该表无内置清理机制，需自行创建作业定期处理）。

  -- 查看表大小
  EXEC sp_spaceused 'dbo.MSchange_tracking_history';
  

• 分析等待统计：查询系统等待信息，排查是否存在与该表相关的锁等待（如LCK_M_X）或IO等待（如PAGEIOLATCH_*），定位性能瓶颈的具体来源。

  SELECT wait_type, wait_time_ms, signal_wait_time_ms, wait_resource
  FROM sys.dm_os_wait_stats
  WHERE wait_type LIKE '%LCK%' OR wait_type LIKE '%PAGEIOLATCH%'
  ORDER BY wait_time_ms DESC;
  

• 验证SP3补丁完整性：确认SQL Server 2016 SP3是否完整安装，部分组件缺失可能导致内部清理逻辑异常，可通过SELECT @@VERSION确认版本号，并重新运行补丁安装程序验证。

内容的提问来源于stack exchange，提问作者David