拥有用于复制BLOB（类型image）的合并发布，就我的数据量而言，tempdb磁盘I / O很高。发布是仅下载的，没有筛选器。
高磁盘I / O是由同步引起的（当没有订阅者进行同步时，一切正常），这与订阅者数量密切相关。即使同步之间在Publisher上没有任何数据更改，也会发生这种情况，这使我感到困扰。
- 复制表的大小：7MB（总行数约为100）
- tempdb I / O：写入速度约为30 MB /秒（日志和数据文件）
- 订户数量：略多于100个，每个订户每30分钟同步一次（或多或少均匀）。
- 保留期限设置为14天
在发布服务器上使用SQL Server 2008，在订阅服务器上使用SQL Server 2005-2008R2。所有订户都使用Web同步。
此外，在订户处进行同步需要花费大量时间，并且多次发生replmerg.log以下情况：
DatabaseReconciler, 2015/04/21 12:13:40.348, 3604, 25088, S2, INFO: [WEBSYNC_PROTOCOL] Sending client ReconcilerPhase WebSyncReconcilerPhase_RegularDownload DatabaseReconciler, 2015/04/21 12:13:47.063, 3604, 25194, S2, INFO: [WEBSYNC_PROTOCOL] Received server ReconcilerPhase WebSyncReconcilerPhase_LastRegularDownload
尝试@stream_blob_columns打开和关闭设置无效。
该问题是：这是个好主意，用合并复制到这些斑点发送到用户？我们还有其他出版物（尽管它们没有BLOB列），其中包含大量数据，而没有tempdb问题。是SQL Server缺陷还是安装错误？
发布服务器和分发服务器位于同一实例SQL Server 2008 SP4上，不能确定订阅服务器，其中一些可能不是最新的。无论如何，如果看来有帮助，我可以准备一个测试环境，只有很少的订阅者拥有受控版本。
已确认是由于执行了tempdb过多sys.sp_MSenumgenerations90。检查MSMerge_genhistory表，发现超过120万条记录pubid为空。
找到了与复制大师的对话：
执行sp_mergemetadataretentioncleanup无效。
在这样的情况（在MSmerge_genhistory中的行过多）中找到了一个注释，其中删除pubidnull和genstatus= 1的行有助于修复复制。
删除的行为pubid空（这意味着所有订阅服务器都已同步，而没有同步-将在“手动模式”下重新初始化），并且磁盘IO再次恢复正常！
我有一种感觉，这种情况可能是由于以下事实造成的：我的所有订户都通过WebSync匿名了，并且大多数订户具有相同的主机名。我将尝试检查-hostname键是否有助于不增加中的记录MSmerge_genhistory。