我们有一个生产网站，在使用高峰期每天多次遇到 SQL 2005 服务器连接错误：
建立与服务器的连接时发生错误。连接到 SQL Server 2005 时，此故障可能是由于在默认设置下 SQL Server 不允许远程连接造成的。（提供者：命名管道提供者，错误：40 - 无法打开与 SQL Server 的连接）
我们当然正在调查其他途径，但到目前为止，我们还没有在 SQL 方面看到任何异常情况。我们想知道这是否可能是命名管道问题，或者如果我们强制 Web 服务器改用 TCP/IP，我们是否会看到同样的情况。所以我的问题是：
- 有人见过这样的问题吗？我对这个错误所做的大部分搜索都是针对那些因为表面区域配置混乱而根本无法与他们的 SQL 服务器交谈的人。那不是我们的情况。
- 两者有什么区别？他们是否以不同的方式进行名称解析？这些服务器不是域成员，它们被隔离在自己的 DMZ 中，如果这有任何改变的话。
- 互联网团队在 Web 服务器上设置了 SQL 别名：“mySQLserverName - tcp/ip - xxx.xx.x.xx, 1433”。这是否仅用于 TCP/IP 解析，而不用于命名管道？这可能是问题的一部分吗？
- 如果我确实想强制使用 TCP/IP 而不是命名管道，那么推荐的方法是什么？这个 Microsoft KB说我可以通过修改连接字符串来做到这一点。这个 MSDN 论坛帖子说我可以修改本机客户端配置协议的“首选顺序”。我想我也可以完全禁用 SQL 服务器上的命名管道，但这似乎有点激烈，并且可能不是在生产机器上尝试的东西。
如果这仅在高峰时间发生，并且来自同一应用程序的其他连接尝试工作正常，那么您可能会遇到 SQL 服务器上的内存争用或超时问题。
通常，命名管道适用于 LAN 通信或其他快速、稳定的网络，但它比 TCIP/IP 套接字更繁琐（即开销更大），因此对于较慢的连接（例如通过 WAN）来说不一定是一个好主意。
当您说每台服务器都隔离在自己的 DMZ 中时，您的意思是您有多个 DMZ 网络并且每台服务器都在不同的网络中吗？如果是这样，请让您的 Internet 团队检查防火墙日志中是否存在丢失/拒绝/失败的连接。如果您的服务器位于不同的子网上，您可能希望将 TCP/IP 设置为首选协议。
这里有几篇讨论协议差异的文章：
通常，对于本地和基于 WAN 的服务器，我们只在连接字符串中使用 TCP/IP（具有非默认端口号）并且没有可伸缩性问题。
您可以通过在连接字符串中使用 server=dbservername,1433（即指定端口号）来强制使用连接以使用 TCP/IP。
我们通常将命名管道保持打开状态，因为它允许您在 SQL Management Studio 上查看服务器状态的“绿色”/“红色”指示器。
我会查看服务器的总体运行状况，尤其是网络负载（连接/冲突）和 RAM 使用情况（SQL Server PerfMon 计数器）。有时，您可能会在非常繁忙的服务器上遇到连接池/释放问题（通常在每秒有 1,000 个连接时）。