背景：
最近一段时间，有一个发布订阅在晚上总是报延时，由于晚上在copy备份占用带宽，而且晚上没有人使用订阅上的数据，所以也一直没有去看，最近有时间，上去看了下，发现诸多问题，服务器是12GB内存16CPU.
排查步骤及解决办法：
1.查看到当前大量的PAGEIOLATCH_SH等待信息，执行的是分发的读程进命令SQL-sp_MSget_repl_commands，怀疑IO/内存有压力，理论上分发库不大，应该可以全部缓存在内存中：
2.于是查看分发库大小，发现有22GB，再查看表msrepl_commands数据量，居然有4000W，16GB大小：
3.需要再排查一下是发布到分发和分发到订阅是哪个出现了延时，结果表明是分发到订阅出现了延时(null代表在指定时间内没有反回数据，也就是数据没有传输到)，采用的方法：tracer tokens
4.查看MSdistribution_history表信息，发现每5分钟记录的分发进程中，读取进程reader fetch时间都很大，都在300秒以上，初步判断为从分发到订阅这个步骤中，读出现了延时，写没有延时：
5.由于读进程要从MSrepl_commands中读取，而这个表又特别大，在读取时有PAGEIO*等待，所以怀疑跟这个表有直接关系，于是需要找到这个表为什么会这么大；
6.进一步查找表大的原因，查看分发属性，我们可以看到至少保留为0，那也就是说清除这个表的那个job出现了问题；
7.于是查看job，发现没有这个job，正常这个job名称为：Distribution clean up: distribution，同时发现也缺少job:Agent history clean up: distribution, 猜测可能是被误删除了，接下来从另外一台分发服务器上，生成这两个job的脚本，到这台分发上来执行，注意需要改servername。8.接下来运行job:Distribution clean up: distribution(运行了很长时间)，之后再查表MSrepl_commands，大小变成100+.
9.之后再观察上面1中的这些等待没有了、运行上面3已经没有延时，再查看表MSdistribution_history表信息，结果如下，可以看到reader fetch变成了0，问题解决。
10.继续运行两天，发现延时问题没有再出现。
nzperfect 2013.01.09
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。