在Publisher database中更新一个big table，数据行数是3.4亿多。由于没有更新 clustered Index key，因此，只产生了3.4亿多个Update Commands 和 1个Transaction，数据量还是很大的。在 Log reader 将 Commands 插入到 distribution.dbo.MSrepl_commands 的过程中，几乎所有的Distribution Agent 都抛出 Performance Critical 的Warning，Log Reader 插入Commands的速度十分缓慢，初步预测，仅仅是将Update Commands插入到 MSrepl_commands的时间就需要12hours。为了不影响其他数据的同步，我打算将该表的Publication 和 Subscription 删除，然后手动同步数据。
Scenario1：
在Subscriber中，成功删除Subscription。链接到Publisher，在删除Publication时，SSMS 先是 NO Responding，然后报错。查看Subscriber运行的Session，发现 Distribution Agents 的 sessions 都被block。删不掉Publication的原因，估计是Log Reader 正在读取Commands，这个操作不能被异常终止。为了避免损坏其他数据，只能等待 Log Reader 将 Update commands 插入到 distribution中了。Leader只给一天的缓冲期，必须在明天解决这个问题。
Scenario2：
在Log Reader 将 Publisher的所有commands都插入到 distribution.dbo.MSrepl_commands 之后，由于在Scenario1已经将Subscription删除，Update Commands没有同步到Target table，但也没有被删除，依然存储在MSrepl_commands中。如果运行 Distribution clean up job，减少 Commands Retition的时间，肯定会影响其他数据的同步。
EXEC dbo.sp_MSdistribution_cleanup @min_distretention = 0, @max_distretention = 120
所以，必须手动从 MSrepl_commands 删除相应的commans，同时必须从 distribution.dbo.MSrepl_transactions 删除相应的Transaction。
根据 MSrepl_transactions 中的 publisher_database_id 和 entry_time，筛选出相应的 xact_seqno（Replication用于同步Commands的事务ID），根据publisher_database_id 和 xact_seqno 查看 MSrepl_commands 的中命令的数量，用以 verify 事务的 xact_seqno。
select count(0)from distribution.dbo.MSrepl_commands with(nolock)where xact_seqno=0x000055A8000069610001 and publisher_database_id=19
也可以使用 sp_browsereplcmds 查看 msrepl_commands 中的SQL语句，最终确定事务的 xact_seqno，根据 publisher_database_id 和 xact_seqno从 distribution 删除commands 和 transaction。
deletefrom distribution.dbo.MSrepl_commands where xact_seqno=0x000055A8000069610001 and publisher_database_id=19deletefrom distribution.dbo.MSrepl_transactionswhere xact_seqno=0x000055A8000069610001 and publisher_database_id=19
耗时 3个小时，终于将commands 和 transaction删除，Replication 恢复正常。
Mark：在更新Big Table时，最好将 SQL Server Replication关闭，手动在Publisher 和 Subscriber中更新，在更新完成之后，再重建Replication。