我在使用 SQL Server 时遇到了严重的问题 - 特别是事务复制。
我们曾经有一台装有 SQL 2000 的 Windows 2003 物理机。我们称之为“WebDB”。该服务器位于数据中心，我们通过 WAN 连接到它。
回到办公室，我们有一台装有 SQL 2008 的 Windows 2008。我们称之为“OfficeDB”，它具有事务复制发布，包含大约 20 个目录。它毫无问题地复制到了这台物理服务器。
最近，我们在虚拟机（Esxi）托管环境中部署了一台新服务器。此环境也通过 WAN 连接。
该服务器安装了 SQL 2008 R2。它有 12GB 内存。
我们备份了原始 WebDB，并将其恢复到新的 vWebDB。我将其配置为 OfficeDB 中我们出版物的订阅者。
初始化后，一切似乎都运行正常。
我们将我们的网络应用程序切换为使用新的 vWebDB 服务器。
CPU 似乎一直在 100% 左右徘徊，网络应用程序上没有任何变化 - 查询（虽然效率有些低下 - 我会在适当的时候研究这个问题）保持完全相同。
复制延迟在 10 分钟到 2 小时之间（不定）
如果我禁用复制，vWebDB 服务器似乎会平静下来，并且 CPU 使用率会下降到 50-60% 左右
然而，启用复制后，数据库最终会开始超时，并且用户会收到错误等等......
值得注意的事情：
我直接将原始数据库备份/恢复到新的虚拟硬件上。问题是 MDF/LDF 文件被拆分到 2 个虚拟磁盘上。这在虚拟环境中是好的做法吗？
分发服务器曾经（现在仍然）位于 OfficeDB 服务器上。分发代理是分发者（推送订阅）
让我感到困惑的是，这个设置在旧机器上运行良好。我愿意听取修复此问题的建议。如果相关问题，我将编辑此帖子并回答问题。
答案1
订阅是设置为推送还是拉取？如果设置为拉取，我建议将它们移至推送，这样可以减轻订阅者的负担，看看是否有帮助。此外，这是一种初始化订阅者的奇怪方法（从另一个订阅者的备份中初始化）。您是否在复制监视器中看到任何错误？分析器对负责传递复制命令的存储过程有何评价？如果有一个正在运行，它的查询计划是什么样的？