事务复制是否有可能获得1秒以下的延迟？

Question

我们的数据库体系结构由两个Server 2005服务器组成，每个服务器都具有相同数据库结构的实例:一个用于所有读取，一个用于所有写入。我们使用事务性复制来保持读数据库的更新.

这两台服务器确实很高规格(写服务器有32 of的RAM)，并通过光纤网络连接。

在决定这个体系结构时，我们被引导相信将数据复制到读取服务器的延迟将是几毫秒(显然取决于负载)。在实践中，即使在最简单的情况下，我们也看到了大约2-5秒的延迟，这是不能令人满意的。在最简单的情况下，我的意思是更新写db上单个表中单个行中的单个值，并查看在读数据库中观察新值所需的时间。

我们应该考虑哪些因素来实现1秒以下的延迟？这是可以实现的吗？

或者，我们是否应该考虑另一种复制模式？数据和日志文件位置的最佳实践是什么？

编辑

感谢大家的建议和洞察力-我相信，我们正在经历的潜伏期是正常的；我们被我们的db托管公司错误地领导了什么等待等待时间！

我们正在使用在这篇MSDN文章底部附近描述的技术(在标题“缩放数据库”下)，并且未能正确处理此警告：

创建这种专门数据库的结果是延迟:现在需要时间才能将写分发给读者数据库。但是如果你能处理延迟，缩放的潜力是巨大的。

我们现在正在考虑实现对缓存机制的更改，当数据项被认为是“易失性”时，这种机制会强制从写数据库读取数据。

Answer 1

不是的。即使使用快速硬件，使用Server事务复制也不太可能实现子1s延迟时间。

如果你能得到1-5秒的延迟，那么你做得很好。

来自这里

使用事务性复制，订阅服务器可能比发布服务器落后几秒钟。只要延迟几秒钟，订阅服务器就可以很容易地用作报表服务器，卸载昂贵的用户查询，并从发布服务器向订阅服务器报告。 在下面的场景中(使用本节后面所示的Customer表)，订阅服务器仅落后发布服务器4秒钟。更令人印象深刻的是，60 %的时间都有2秒或更短的延迟。从发布服务器插入或更新记录到实际写入订阅数据库的时间开始。

Answer 2

我会说这是绝对有可能的。

我想看看：

• 你的网络 在两个服务器之间运行ping命令，看看是否有任何问题 如果服务器彼此相邻，则应该有<1ms。
• 服务器上的瓶颈 这可能是网络流量(卷)。 就像网卡没有被配置为1GB/秒一样 防病毒或其他东西
• 对一些查询进行一些分析，看看是否可以识别索引或锁定，这可能是一个问题。
• 查看读取数据库上的任何选择是否会阻塞写入。 添加with (nolock)，看看这对您正在分析的一两个查询是否有影响。

本质上，您有一个复杂的系统，您有问题，您需要确定哪个组件是问题，并修复它。

如果需要运行的报表/选择需要更新，则事务复制可能是最好的。如果没有，您可以查看日志传送，尽管这样会增加每次导入的停机时间。

对于数据/日志文件，请确保它们位于不同的驱动器上，以便最大限度地提高性能。

Answer 3

关于事务复制，需要记住的一点是，单个更新现在需要执行多个操作才能发生更改。

首先更新源表。接下来，日志阅读器将看到更改并将更改写入分发数据库。接下来，分发代理将看到分发数据库中的新条目并读取更改，然后在订阅服务器上运行正确的存储过程来更新行。

如果您监视这两个服务器上的语句运行时间，您可能会看到它们在几毫秒内运行。然而，等待日志读取器和分发代理时的滞后时间是，它们需要做一些会杀死您的事情。

如果您确实需要子秒处理时间，那么您将需要编写自己的处理引擎来处理从一个服务器移动到另一个服务器的数据。我建议使用Service来处理这个问题，因为一切都是Server的本机，不需要编写第三方代码。