对于发布数据库的数据大量操作时，会使日志扫描并读取太多，会导致分发堵塞很久。也有一些解决方法，参考 《SqlServer 复制中将大事务分成小事务分发》 ， 《SqlServer大量更新引起同步链延时问题》 。当然也可以使这些数据不分发，尤其是新表，数据尚未让用户使用，可以在日志读取器跳过扫描标识为 “复制” 的事务。

注: 以下模拟操作，操作都在发布数据库执行!

1. 将队列读取器代理  -Continuous 去掉，使日志读取器不连续扫描事务日志
2. 更新数据
3. 启用日志读取器,数据正常同步到订阅中
4. 再次更新数据,执行以下操作

将队列读取器代理  -Continuous 去掉的操作如下：

过程脚本如下，不详细说明：

--  因为日志读取器停止,分发表还没有刚才更新的记录
SELECT * FROM distribution.dbo.MSrepl_commands
SELECT * FROM distribution.dbo.MSrepl_transactions--  但是事务日志中标识为复制(REPLICATE) 的日志增多了
SELECT count(*) FROM ::fn_dblog(NULL, NULL) WHERE Description='REPLICATE'--  查看最早的分布式和非分布式复制事务
--  https://msdn.microsoft.com/zh-cn/library/ms182792.aspx
DBCC OPENTRAN() WITH TABLERESULTS; REPL_DIST_OLD_LSN        (535:23:10)
REPL_NONDIST_OLD_LSN    (535:26:1)--  转换上面的整数为16进制
SELECT cast(cast(535 as int) as binary(4)) + cast(cast(23 as int) as binary(4)) + cast(cast(10 as int) as binary(2))
SELECT cast(cast(535 as int) as binary(4)) + cast(cast(26 as int) as binary(4)) + cast(cast(1 as int) as binary(2))(534:2536:18) >>> 0x00000217:00000017:000A
(534:2552:1) >>>  0x00000217:0000001A:0001--  在事务日志中的记录
select [Current LSN],[Operation],[Transaction ID],Left([Description],20)
from::fn_dblog('0x00000217:00000017:000A','0x00000217:0000001A:0001')--  将事务日志中标识为复制的记录全部标记为已分发,之后日志读取器将不扫描这些记录
--  ( 只有当 xactid 和 xact_seqno 都为 NULL 时，reset 才有效。)
--  https://msdn.microsoft.com/zh-cn/library/ms173775.aspx
exec sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1@reset = 1 则日志中所有复制的事务将标记为已分发;
@reset = 0 则事务日志将重置为第一个复制的事务，事务将重新读取和发布;--  查看当前没有分发的事务（保留在事务日志中尚未发送到分发服务器的事务）
--  https://msdn.microsoft.com/zh-cn/library/ms175114.aspx
exec sp_replshowcmds--  再查看打开的事务,事务也不存在了
dbcc opentran () with tableresults; --  刷新项目缓存(为提高效率，项目定义存储在缓存中)
--  https://msdn.microsoft.com/zh-cn/library/ms174992(v=sql.120).aspx
exec sp_replflush--  此时再次更新其他行数据,启用日志读取器代理,该行数据能正常同步到订阅;之前未同步的,则不会同步.

最后把 -Continuous 添加会日志读取器中！完成！（或者停止日志读取器代理也可以）

参考：Using sp_repldone to mark all pending transactions as having been Replicated