连接到SQL 2005的Sporatic连接问题 – 命名pipe道与TCP / IP问题?

我们有一个生产网站,在高峰使用期间,每天都有几次发生SQL 2005服务器的定期连接错误:

build立到服务器的连接时发生错误。 连接到SQL Server 2005时,这种失败可能是由于在默认设置下SQL Server不允许远程连接。 (提供程序:命名pipe道提供程序,错误:40 – 无法打开连接到SQL Server)

我们当然在研究其他途径,但到目前为止,我们还没有在SQL方面看到任何不寻常的东西。 我们想知道这是否可能是命名pipe道问题,或者如果我们强制Web服务器使用TCP / IP,我们是否会看到相同的事情。 所以我的问题是:

  • 任何人看到这样的问题? 我对这个错误所做的大部分search都是因为表面区域configuration混乱而无法与他们的SQL服务器通信的人。 那不是我们的情况。
  • 两者有什么区别 ? 他们是否以不同的名称parsing? 这些服务器不是域成员,如果它们改变了任何东西,它们就被隔离在它们自己的DMZ中。
  • 互联网小组在Web服务器上设置了一个SQL别名:“mySQLserverName – tcp / ip – xxx.xx.x.xx,1433”。 这只会用于TCP / IPparsing,而不是命名pipe道? 这可能是问题的一部分吗?
  • 如果我想强制TCP / IP而不是命名pipe道,build议的方法是什么? 这个微软KB说我可以通过修改连接string来完成。 此MSDN论坛主题说我可以修改本机客户端configuration协议的“首选顺序”。 我想我也可以完全禁用SQL服务器上的命名pipe道,但是这看起来有点激烈,可能不是在生产环境中尝试的东西。

通常,我们只在连接string(使用非默认端口号)中使用TCP / IP,并且对于本地服务器和基于湾的服务器都没有可扩展性问题。

您可以使用连接string(即指定端口号)中的server = dbservername,1433来强制使用连接来使用TCP / IP。

我们通常会打开命名pipe道,因为它允许您在SQL Management Studio上看到服务器状态的“绿色”/“红色”指示器。

我会看看服务器的一般健康状况,尤其是networking负载(连接/冲突)和内存使用情况(SQL Server PerfMon计数器)。 有时候,在非常繁忙的服务器上(通常每秒有1000个连接),您可能会遇到连接池/发布问题。

如果这只发生在高峰时间和来自同一个应用程序的其他连接尝试正常工作,那么你可能会跑到SQL服务器上的内存争用或超时问题。

通常,命名pipe道对局域网通信或其他快速,稳定的networking来说是很好的,但是比TCIP / IP套接字有点烦琐(即更多的开销),所以对于较慢的连接(如通过WAN)来说不一定是个好主意。

当你说每个服务器在他们自己的DMZ中是隔离的,你的意思是说你有多个DMZnetworking,每个服务器都是不同的? 如果是,请让您的Internet小组检查防火墙日志中是否存在丢弃/拒绝/失败的连接。 如果您的服务器位于不同的子网上,则可能需要将TCP / IP设置为首选协议。

以下是一些讨论协议差异的文章:

  • selectnetworking协议 (Technet)
  • 命名pipe道提供程序,错误:40 – 无法打开连接到SQL Server (MSDN博客)