我通过专用 VPN 连接在两台服务器之间运行事务复制。数据库相当大，所以我最初使用备份和恢复方法将初始快照传送到订阅者机器，然后让它从那里应用增量事务。
一切都运行良好，直到 VPN 线路变得不稳定（它偶尔会这样做），此时复制过程很容易锁定。当我查看订户端时，有一些 SQL 进程似乎已挂起，并且在订户数据库和表上持有锁。疯狂的是，这些进程来自复制服务。我可以向您保证（通过反复试验），除了复制本身之外，没有其他进程正在锁定该数据库。
那么，为什么复制过程会像这样绊倒自己呢？为什么它会因为失去网络连接而挂起？有什么建议可以让它更可靠吗？
我听说过有关 vpn 连接的此类问题。这里有一个帖子可以帮助你。
另一种选择，如果您有持续的问题，并且根据您对速度和功能的要求，可能是使用日志传送。在我看来，这可以提供一种更有弹性的数据移动方式——至少从网络的角度来看是这样。
在 SQL Server 2005 中，它们允许您使用 Web 服务进行复制。这可能不允许您放弃 VPN，但由于 Web 服务的连接驱动较少，这可能有助于解决问题。我自己没有尝试过，所以我不知道结果可能是什么。
至于锁，我们害怕地认为很多东西都被锁住了，但事实证明复制监视器只是在自己锁定，所以在查看锁时请确保您没有打开它。不过，这听起来不像你的问题。
我会问一些问题，也许他们可以给你一些想法，因为我在这里也没有线索。
复制器有没有办法在尝试开始复制之前测试连接性？有没有办法将连接测试放入您用于执行复制的任何脚本中？有没有办法让脚本在失败的情况下保释？