SQL Server 2014 Distribution Cleanup作业访问MSrepl_commands报错原因排查

• 已知产品Bug：你当前使用的SQL Server 2014 SP3 CU2（12.0.6214.1）存在多个和复制系统表查询相关的已知未修复Bug，其中就包含过滤查询MSrepl_commands的publisher_database_id字段时，可能触发内部一致性错误的问题，该类问题属于SQL Server引擎层面的逻辑缺陷，不会被DBCC校验检测到。
• 内存缓存页逻辑损坏：DBCC CHECKDB/CHECKTABLE默认读取磁盘上的持久化数据做校验，如果数据页加载到SQL Server缓存池后，因内存硬件故障、内存页改写异常、缓存池污染等问题出现逻辑损坏，查询时读取内存中的损坏页就会触发报错，而DBCC校验磁盘数据时不会发现异常。可通过执行DBCC DROPCLEANBUFFERS清空缓存后重新执行查询验证，如果报错消失即可定位为此类问题。
• 统计信息损坏：针对publisher_database_id字段的统计信息如果存在元数据结构损坏，查询优化器生成执行计划、或者执行期读取统计信息做基数估算时会触发内部错误，而DBCC默认不校验统计信息的完整性，可通过执行DBCC CHECKSTAT ('distribution', 'dbo.MSrepl_commands')确认，或者直接更新统计信息UPDATE STATISTICS dbo.MSrepl_commands WITH FULLSCAN后重试查询验证。
• 读未提交隔离级别的并发异常：你执行的查询使用了WITH (NOLOCK)（读未提交隔离级别），如果此时有并发的复制写入、清理作业正在修改MSrepl_commands的数据，可能会读取到页拆分、行版本变更的中间不一致状态，触发瞬态的内部一致性报错，这类问题属于偶发的隔离级别副作用，不是数据本身损坏，可切换为快照隔离级别或者去掉NOLOCK提示重试验证。
• 复制元数据业务一致性损坏：MSrepl_commands是复制专属系统表，其数据和MSpublication_databases等其他复制系统表的数据存在业务关联，如果publisher_database_id=28对应的复制元数据记录被异常删除、修改，会导致查询MSrepl_commands时引擎读取关联复制元数据触发内部错误，这类业务层面的元数据不一致不会被通用的DBCC完整性校验检测到，可查询distribution.dbo.MSpublisher_databases确认id=28的记录是否存在且状态正常。
• 存储层加密/压缩异常：如果数据库底层使用了第三方存储加密、透明数据加密（TDE）之外的自定义压缩工具，可能存在特殊查询路径下数据解密/解压异常的问题，DBCC读取数据的路径和普通业务查询路径不一致时，就会出现DBCC校验无错但普通查询报错的情况。

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