![连接到 SQL 2005 的偶尔出现的连接问题-命名管道与 TCP/IP 问题?](https://linux22.com/image/486230/%E8%BF%9E%E6%8E%A5%E5%88%B0%20SQL%202005%20%E7%9A%84%E5%81%B6%E5%B0%94%E5%87%BA%E7%8E%B0%E7%9A%84%E8%BF%9E%E6%8E%A5%E9%97%AE%E9%A2%98-%E5%91%BD%E5%90%8D%E7%AE%A1%E9%81%93%E4%B8%8E%20TCP%2FIP%20%E9%97%AE%E9%A2%98%EF%BC%9F.png)
我们有一个生产网站,在高峰使用期间,该网站会定期遇到与 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 知识库说我可以通过修改连接字符串来做到这一点。此 MSDN 论坛主题说我可以修改本机客户端配置协议的“首选顺序”。我想我也可以完全禁用 SQL 服务器上的命名管道,但这似乎有点过分,可能不适合在生产环境中尝试。
答案1
通常,我们仅在连接字符串中使用 TCP/IP(具有非默认端口号),并且对于本地和基于 WAN 的服务器都没有可扩展性问题。
您可以通过在连接字符串中使用 server=dbservername,1433(即指定端口号)强制使用连接使用 TCP/IP。
我们通常保持命名管道打开,因为它允许您在 SQL Management Studio 上看到服务器状态的“绿色”/“红色”指示器。
我会查看服务器的总体运行状况,尤其是网络负载(连接/冲突)和 RAM 使用情况(SQL Server PerfMon 计数器)。有时,在非常繁忙的服务器上(通常每秒有 1,000 个连接时),您可能会遇到连接池/释放问题。
答案2
如果这种情况仅发生在高峰时段,并且来自同一应用程序的其他连接尝试运行正常,那么您可能遇到了 SQL 服务器上的内存争用或超时问题。
通常,命名管道适用于 LAN 通信或其他快速、稳定的网络,但它比 TCIP/IP 套接字更嘈杂(即开销更大),因此对于较慢的连接(例如通过 WAN)来说不一定是一个好主意。
当您说每台服务器都隔离在各自的 DMZ 中时,您是否意味着您有多个 DMZ 网络并且每台服务器都位于不同的 DMZ 网络中?如果是这样,请让您的 Internet 团队检查防火墙日志以查找断开/拒绝/失败的连接。如果您的服务器位于不同的子网上,您可能需要将 TCP/IP 设置为首选协议。
以下几篇文章讨论了协议的差异:
- 选择网络协议(科技网)
- 命名管道提供程序,错误:40-无法打开与 SQL Server 的连接(MSDN 博客)