SQL Server 2000查询响应时间在两台服务器之间超过800毫秒

1. 如果您的DNS导致caching的IP地址（应该是）超过800毫秒，那么您的networking设置存在严重问题。 恕我直言。 你可以看到，如果这是一个问题，使用ping。

2. 使用traceroute来确保数据包在两台计算机之间使用有效的路由。 这很容易做到，所以在你摆弄其他东西之前值得一试。 如果路线上有很多跳，也许超过两三个，找一个networking人，问他为什么这样。

3. 当试图解决SQLnetworking问题时，最好使用一个非常简单的查询，如“SELECT GETDATE（）”，并使用一个简单的查询工具，如SQLCMD.EXE。 简单的查询意味着服务器不必花费大量的时间来parsing查询，不会有任何重大的locking或阻塞，并且查询不会通过networking带回数百万行数据。 简单的查询工具意味着您不必担心IIS可能会或可能不会做什么。 如果IIS服务器上没有安装SQLCMD.EXE，OSQL.EXE或类似工具，则可能需要编写一个小小的psh或vbs脚本来testing与SQL Server的连接。 如果您没有对IIS服务器的访问权限，则可以编写一个特殊的ASP页面，该页面只运行该简单的查询，并返回结果以及运行时间。

4. 如果我不得不猜测这个问题，那么将会是这样 – >尤其是对于较老的设备和驱动程序，避免依靠NIC上的“自动协商”设置。 将两张卡手动设置为相同的设置。

我知道这是一个阻力，但我个人看到这清除了十几个类似的问题，networking家伙被打倒。 （毕竟，这些服务器是服务器，而不是像插入许多不同的交换机，并且需要重新协商链路速度或双工设置。）

您还可以通过使用性能监视器观察NIC（以MB /秒为单位）上的数据速率来查看此问题。 一旦你build立了一个基线，改变网卡上的设置并再次观察。

你通常可以改变这些设置“现场”，但我不会尝试在高峰负载时间第一次摆弄这些设置。 如果有的话，在testing环境中进行试验会更好。 如果你有一个维护窗口，这将是最好的。 如果服务器中只有一个NIC，请注意不要将NIC设置为不能与交换机通信，或者您可能不得不请求某个人物理地login到控制台，这对每个人来说都是一件坏事。

有很多可能的原因。 例如，可能是networking适配器驱动程序的问题之一。

你将不得不检查SQL连接是否是瓶颈，或者是一个普通的networking问题。 尝试从Web服务器发出“select getdate（）”命令，查看是否每个查询都受到影响。

数据库服务器ping是否也慢？ 此外，尝试使用IP地址，而不是服务器名称 – 也许这是一个DNS解决问题。