1

我已经在相对较慢的 VPN 连接的不同端的两个 SQL Server 之间设置了事务复制。设置是您的标准“立即加载快照”类型的事情，它在初始化订阅后做的第一件事是删除并重新创建订阅者端的所有表，然后开始对所有数据进行 BCP。问题是有几张表中有几百万行，并且该过程要么 a) 需要很长时间，要么 b) 完全失败。当我查看复制监视器时，我不断收到的消息是：

  • 该进程正在运行并正在等待来自服务器的响应。
  • 查询超时已过期
  • 初始化

然后它会尝试重新启动批量加载过程（跳过它已经加载的任何 BCP 文件）。

我目前被困在它一遍又一遍地这样做的地方。它已经运行了几天了。

我的问题是：

  1. 鉴于网络连接速度如此之慢，我能做些什么来改善这种情况吗？也许一些设置或什么？只要过程不超时，我不介意等待很长时间。

  2. 有一个更好的方法吗？也许做一个备份，压缩它，复制它然后恢复？如果是这样，复制过程如何知道在开始应用事务时从哪里获取，因为更新将在我进行备份和恢复并在另一端运行之间发生。

4

2 回答 2

3

是的。您可以手动应用初始快照。

对我来说已经有一段时间了，但是链接（到 BOL）可以替代设置订阅者。

编辑：从 BOL How-tos，从备份初始化事务订阅者

于 2008-12-05T21:34:28.423 回答
1

在 SQL 2005 中，您有一个“紧凑快照”选项，可让您减小快照的总大小。当通过网络应用时，快照项目“旅行”压缩到订阅者，然后在订阅者处展开。

我认为您可以通过比较标准快照和压缩快照的大小来轻松计算潜在的速度增益。

顺便说一句，对于合并复制，这里有一个（非常）类似的问题，但我认为在快照级别没有区别。

于 2008-12-07T17:14:10.443 回答