非常大的表的 SQL Server 事务复制

Question

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

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

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

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

我的问题是：

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

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

Answer 1

是的。 您可以申请initial snapshot manually。

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

编辑：来自 BOL How-tos，Initialize a Transactional Subscriber from a Backup

Answer 2

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

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

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