SQL SERVER复制拓扑结构中，订阅端宕机后的处理.....（二）
接着上一章
当订阅端长时间没有连上，且同时在发布端有大量的insert语句，来看看：
USE mysales_normal GO INSERT INTO [mysales_normal].[myinventory].[Vendor] SELECT addressid,substring(addressline1,1,20), substring(city,1,10), substring(city,1,10), substring(city,1,5), substring(city,1,10) FROM AdventureWorks.person.ADDRESS WHERE AddressID>10000
这条语句插入了18510条语句，等待吧！可以从replication monitor可以得知未发送的命令：
SELECT count(*) FROM distribution.dbo.msrepl_commands (nolock) dm WHERE dm.publisher_database_id=7 and article_id=8
如果运行 【Distribution clean up: distribution】job,是没有任何效果的，因为命令没有发送到订阅端！
这时已经是第二天了，一直断了10多个小时，插入insert tracer,会发现distributor to subscriber的状态是pending,未发送命令多了一条，如图所示：
启动命名实例后会发现distributor 把挂起的命令立即发送到subscriber，如图所示：
再来看看replication monitor中的undistributed comands选项：
只剩下最后一条insert tracer命令没有被【Distribution clean up: distribution】这个job清理掉，看看相关msrepl_commmands中的命令：
SELECT count(*) FROM distribution.dbo.msrepl_commands (nolock) dm WHERE dm.publisher_database_id=7 and dm.article_id=8
结果为0
再来看看未被清理掉的是什么命令，使用如下的脚本，这个时候不能使用@article_id这个参数
exec distribution..sp_browsereplcmds @publisher_database_id=7
订阅端表vendor已经有相应的数据了！
总结：1：再一次的证明了undistributed commands 仅仅是显示相应发布项在msrepl_commands中的命令，包括已发送的和未发送的命令，这个命令数字只能作为辅助判断，
为了证明这一点，可以手动的暂停【Distribution clean up: distribution】job，会发现undistributed commands 会永远不变。
2： 【Distribution clean up: distribution】也只是清理掉已发送的命令，10分钟运行一次，关键的判断还是要通过[insert tracer]来确认，这个命令的详细解释点击这
3：在做这个测试寻找资料中，发现这个链接，在 FQA FOR Replication 中微软给出了一个总结式的结论，抄录如下：
Does replication resume if a connection is dropped
Yes. Replication processing resumes at the point at which it left off if a connection is dropped. If you are using merge replication over an unreliable network,
consider using logical records, which ensures related changes are processed as a unit.
4：有关复制分发的资料，以下两个站点非常不错，可以常去看看！
