是否有可能通过事务复制获得低于1秒的延迟？

Question

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

两台服务器确实非常高规格（写入服务器有32GB的RAM），并通过光纤网络连接。

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

我们应该考虑哪些因素才能达到低于1秒的延迟？这甚至可以实现吗？

或者，我们应该考虑不同的复制模式吗？数据和日志文件位置的最佳做法是什么？

修改

感谢大家提供的建议和见解 - 我相信我们遇到的潜伏期正常正常;我们的数据库托管公司错误地指导了我们期望的延迟时间！

我们正在使用this MSDN article底部附近描述的技术（在“缩放数据库”标题下），我们未能正确处理此警告：

  

创建此类专用数据库的后果是延迟：写入现在需要时间才能分发到读取器数据库。但如果你能处理延迟，那么扩展潜力就很大。

我们现在正在考虑对我们的缓存机制进行更改，当一个数据项被视为“易变”时，该机制会强制执行来自write数据库的读取。

Answer 1

没有。即使使用快速硬件，使用SQL Server事务复制也不太可能实现低于1秒的延迟时间。

如果你可以获得1到5秒的延迟，那么你表现得很好。

来自here：

  

使用事务复制，它是   订阅者可能只有少数几个   发布者后面几秒钟。有了   延迟只有几秒钟了   订阅者可以轻松地用作   报告服务器，卸载昂贵   用户查询和报告   发布给订阅者。

     

在以下场景中（使用   客户表显示在本文后面   部分）订阅者只有四个   发布者后面几秒钟。甚至   更令人印象深刻，60％的人   时间延迟为2秒   或更少。时间是从   插入记录时或   在发布者处更新，直到它   实际写到订阅   数据库中。

Answer 2

我会说这肯定是可能的。

我会看：

• 您的网络
  在两台服务器之间运行ping命令，看看是否有任何问题 如果服务器彼此相邻，那么你应该具有＆lt; 1毫秒
• 服务器上的瓶颈
  这可能是网络流量（音量）
  就像没有配置1GB /秒的网卡一样 反病毒或其他东西
• 对某些查询进行一些分析，看看是否可以识别可能存在问题的索引或锁定
• 查看读取数据库上的任何选择是否可能阻止写入 添加（nolock），看看这是否会对您正在分析的一个或两个查询产生影响。

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

如果您需要运行的报告/选择需要是最新的，则事务复制可能是最佳的。如果他们不这样做，你可以查看日志传送，虽然这会增加每次导入的停机时间。

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

Answer 3

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

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

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

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