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：有关复制分发的资料，以下两个站点非常不错，可以常去看看！

a: REPLTalk covers Using and Tuning SQL Replication

b:replicationanswers