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

Question

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

这两台服务器确实非常高规格(写入服务器有32GB的RAM),并通过光纤网络连接.

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

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

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

编辑

感谢大家的建议和见解 - 我相信我们所经历的潜伏期是正常的; 我们的数据库托管公司错误地指导了我们期望的延迟时间!

我们正在使用MSDN文章底部附近描述的技术(在"扩展数据库"标题下),我们未能正确处理此警告:

创建这样的专用数据库的结果是延迟:现在需要花时间将分发到读取器数据库.但是,如果你能够处理延迟,那么扩展潜力巨大.

我们现在正在考虑实现对我们的缓存机制的更改,当一个数据项被认为是"不稳定的"时,该机制会强制执行来自write数据库的读取.

Answer 1

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

如果您能获得 1 - 5 秒的延迟，那么您就做得很好了。

从这里：

使用事务复制，订阅服务器可能会落后发布服务器几秒钟。由于延迟只有几秒钟，订阅服务器可以轻松用作报告服务器，将昂贵的用户查询和报告从发布服务器转移到订阅服务器。

在以下场景中（使用本节后面显示的客户表），订阅服务器仅落后发布服务器四秒。更令人印象深刻的是，60% 的时间延迟为两秒或更短。该时间是从记录在发布服务器上插入或更新到实际写入订阅数据库为止的时间。