事务复制中的表大量更新导致无法及时同步

复制存储过程执行应用于事务复制中，当在发布服务器上执行配置的存储过程时，存储过程导致的数据变更不会做为多步骤事务发送到订阅服务器，而仅仅是把执行存储过程的命令发送到订阅服务器。

比如，如果你为一个100万条记录的表增加了一个字段，并且初始化为一个值，如果不使用复制存储过程执行的话，那么这个操作就会形成100万个更新操作发送到订阅服务器，订阅服务器将将进行100万次更新，这个操作通常会花费很长时间，并导致后续的数据变更也无法得到及时的同步。

如果使用复制存储过程执行的话，你可以创建一个存储过程来实现这个更新，并且把这个存储过程添加到事务复制中，然后当你在发布服务器上执行完成这个存储过程后，这个执行操作会衩发送到订阅服务器，订阅服务器将执行同样的调用存储过程的操作来完成这100万记录的更新。

由于在发布和分发服务器之间不存在大量的数据传递，更新操作也不是100万个更新，所以这个操作会很快完成，因此你的同步延迟也会非常小。

复制存储过程的关键是发布项目属性中，为存储过程配置项目属性时，将“复制”项设置为“存储过程执行”，或者是“SP 的序列化事务中执行”，如图所示
（如果你是用T-SQL来创建发布，则是将sp_addarticle 存储过程的@type 参数设置为“proc exec”，或“serializable proc exec”）
其中，“SP 的序列化事务中执行”是推荐的行为，要求你的存储过程是在序列化事务中，也就是SET TRANSACTION ISOLATION LEVEL SERIALIZABLE。

至于原因和详细的资料，可能参考联机帮助：
/zh-cn/library/ms152754(SQL.90).aspx
值得注意的是，由于订阅服务器上的存储过程是可以修改的，所以利用这个，你还可能实现更多的与大批量数据相关的操作。

例如，你可能有一些大表，这些表被同步到报表服务器上，在你的发布服务器上，你只关心最新的数据（可能是最近2年），而在报表服务器上，你需要所有的数据。

所以，在发布服务器上，你可能有一个定期删除历史数据的Job，而在报表服务器上，则不能删除，你可能会考虑通过配置筛选来做到发布上的删除不同步到订阅，但如果某天不小心重新初始化了一次，则数据就丢失了。

而利用复制存储过程执行的话，你可以在发布服务器上定义存储过程的内容为删除，在订阅服务器上定义存储过程为删除并且OUTPUT 到历史表，这样发布和订阅的表是一样的，不担心重新初台化导致数据丢失。

唯一要注意的是毕业设计 9361235@，你在发布服务器上修改存储过程的话，这个修改会同步到订阅服务器，当然，这个问题也容易解决，你可以在存储过程里面判断服务器名字来完成不同的操作，这样就万无一失了。