我在SQL Server上遇到了严重的麻烦 – 特别是事务复制。
我们曾经有一个Windows 2003物理机器，使用SQL 2000.我们称之为“WebDB”服务器位于数据中心，我们通过WAN连接到它。
回到办公室，我们有一个Windows 2008，SQL 2008。我们称之为“OfficeDB”这个事务复制出版物有大约20个目录。 这是复制到这台物理服务器没有问题。
最近，我们在VM（Esxi）托pipe环境中部署了一个新的服务器。 此环境也通过WAN连接。
此服务器安装了SQL 2008 R2。 它有12GB的内存。
我们对原始的WebDB进行了备份，并在新的vWebDB上进行了恢复。 我将其configuration为从OfficeDB发布的订阅者。
初始化后，一切似乎工作正常。
我们将我们的networking应用程序切换到使用新的vWebDB服务器。
CPU似乎不断在100％左右徘徊Web应用程序没有改变 – 查询（虽然有点低效，我会在适当的时候看这个）保持完全一样。
复制延迟在10分钟到2小时的范围内（变化）
如果我禁用复制，vWebDB服务器似乎冷静下来，CPU使用率下降到50-60％
随着复制启用，但最终，数据库开始超时，用户得到错误等…
注意事项：
我做了原始数据库的直接备份/恢复，到新的虚拟硬件上。 与此有关的是MDF / LDF文件被分成2个虚拟磁盘。 这是在虚拟环境中的良好做法吗？
分销商是（现在仍然）在OfficeDB服务器上。 分销代理是distrubutor（推送订阅）
困惑我的东西是这个设置在旧机器上工作正常。 我很乐意提供解决这个问题的build议。 如果相关，我将编辑这个post，回答问题。
订阅是设置为推或拉？ 如果拉，我build议可能将他们推动，以便减less您的订户的一些负载，看看是否有帮助。 此外，这是一个奇怪的方式来初始化订户（从另一个订户的备份）。 您是否在复制监视器中看到任何错误？ 分析器对负责交付复制命令的存储过程的评价是什么？ 如果有一个热点，查询计划是什么样子？