是否有可能获得分
我们的数据库体系结构由两个Sql Server 2005服务器组成，每个服务器都有一个相同数据库结构的实例：一个用于所有读取，另一个用于所有写入。 我们使用事务复制来保持读取数据库最新。
这两台服务器确实非常高（写入服务器具有32GB的RAM），并通过光纤网络连接。
在决定这种体系结构时，我们被认为要复制到读取服务器的数据的延迟时间大约为几毫秒（显然取决于负载）。 实际上，即使在最简单的情况下，我们也会看到约2-5秒的延迟，这是不令人满意的。 通过一个最简单的情况，我的意思是更新写入数据库中单个表中单个行中的单个值，并查看观察读取数据库中新值的时间。
我们应该考虑什么因素来实现低于1秒的延迟？ 这是否可以实现？
或者，我们应该考虑一种不同的复制模式？ 数据和日志文件位置的最佳实践是什么？
编辑
感谢所有的建议和见解 - 我认为我们正在经历的延迟期是正常的; 我们被我们的数据库托管公司误导了什么延迟时间的预期！
我们正在使用MSDN文章底部附近描述的技术（标题为“缩放数据库”），并且我们未能正确处理此警告：
创建这种专用数据库的后果是延迟：写入现在需要花费时间分发给读者数据库。 但是如果你能够处理延迟，那么扩展潜力是巨大的。
我们现在正在考虑实施对缓存机制的更改，该缓存机制在数据项被视为“易失性”时强制从写入数据库读取数据。
不可以。即使使用快速硬件，使用SQL Server事务复制也不可能达到sub-1s的延迟时间。
如果你可以得到1 - 5秒的延迟，那么你表现很好。
从这里：
使用事务复制，订阅者可能会比发布者落后几秒。 延迟时间仅为几秒钟，订阅服务器可以轻松用作报告服务器，将昂贵的用户查询和报告从发布服务器卸载到订阅服务器。
在以下情况下（使用本节后面显示的客户表），订阅者仅比发布者短4秒钟。 更令人印象深刻的是，百分之六十的时间有两秒或更短的延迟。 时间从记录在发布服务器上插入或更新的时间开始计算，直到实际写入订阅数据库为止。
我会说这绝对有可能。
我会看看：
在两台服务器之间运行ping命令并查看是否有任何问题
如果服务器彼此相邻，则应该<1 ms。
这可能是网络流量（音量）
像网卡未配置为1GB /秒一样
反病毒或其他东西
添加（nolock），看看这是否会影响你正在分析的一个或两个查询。
基本上你有一个复杂的系统，你有问题，你需要确定哪个组件是问题并修复它。
如果您需要运行的报告/选择需要更新，则事务复制可能是最好的。 如果他们不这样做，您可以查看日志传送，但这会增加每次导入的停机时间。
对于数据/日志文件，确保它们位于单独的驱动器上，以使性能最大化。
关于事务复制的一点需要注意的事情是，单个更新现在需要发生多次操作才能发生更改。
首先更新源表。 接下来，日志读取器会看到更改并将更改写入分发数据库。 接下来，分发代理程序在分发数据库中查看新条目并读取该更改，然后在订阅服务器上运行正确的存储过程以更新该行。
如果您监视两台服务器上的语句运行时间，您可能会看到它们仅在几毫秒内运行。 然而，在等待日志阅读器和分发代理程序看到他们需要做一些会杀死你的东西的时候，这是滞后时间。
如果你真的需要秒的处理时间，那么你将需要考虑编写自己的处理引擎来处理从一台服务器移动到另一台服务器的数据。 我建议使用SQL Service Broker来处理这种情况，因为这种方式一切都是原生的SQL Server，并且不需要编写任何第三方代码。
链接地址: http://www.djcxy.com/p/42521.html