2

我们在连接到远程安装的 MSSQL 2012 实例的机器上部署了一些应用程序。除了一个应用程序，它们在本地管理员帐户下作为 Windows 服务运行。客户端在 Windows 7 32 位上运行，数据库在 Windows Server 2008 R2 64 位上运行。

我在四分之一的连接尝试中收到此错误：

SqlException (0x80131904): A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
   bei System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
   bei System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()
   bei System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity)
   bei System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, Boolean ignoreSniOpenTimeout, TimeoutTimer timeout, SqlConnection owningObject)
   bei System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(ServerInfo serverInfo, String newPassword, Boolean redirectedUserInstance, SqlConnection owningObject, SqlConnectionString connectionOptions, TimeoutTimer timeout)
   bei System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, TimeoutTimer timeout, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance)
   bei System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance)
   bei System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)
   bei System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnection owningConnection, DbConnectionPool pool, DbConnectionOptions options)
   bei System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject)
   bei System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject)
   bei System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
   bei System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
   bei System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
   bei System.Data.SqlClient.SqlConnection.Open()

我在所有应用程序中使用此连接字符串：

数据源=192.168.0.101\NAMEDINSTANCE；初始目录=数据库；集成安全=False；持久安全信息=False；用户ID=用户；密码=密码

我用无限 ping 请求检查了网络连接，但发生错误时没问题。首先我收到了类似的错误消息，虽然启用了 NamedPipes，但是在停用 NamedPipes（我们没有使用它）之后，上述错误以相同的频率发生。相同的设置正在其他机器上运行。该错误在几周前开始发生，然后才成功运行了大约 3 个月。这是一个离线设置，系统自部署以来没有更新（但我不能保证）。两台机器上的防火墙都关闭了。Windows 和 SQL-Server 事件日志都没有提示。我还更换了网络电缆以排除电缆断裂。

我现在有点卡住了，因为我不知道下一步该去哪里。也许有一些可用的连接字符串调整，或者我可以更改一些配置服务器或客户端。

更新： 在 granadaCoders 的帮助下，我发现 tcp 调用可能会被某些东西过滤掉。我使用 PortQry 进行检查。

portqry -n 192.168.0.101 -e 1433 -p tcp
TCP port 1433 (ms-sql-s service): FILTERED

如果这种情况一直发生，我会说防火墙阻止了我的呼叫，但在这种情况下，可能是某种系统过载导致失去我的请求。接下来要做的事情肯定是通过连接特定端口来检查它是否是 SQL Server Browser 故障。然后更换开关。

更新（2013-07-03）：我编写了一个测试应用程序，它每秒打开一个连接并在故障系统上运行它。有效。我在几个连接中两次在其他应用程序上收到错误，但在我的测试应用程序中的 500 个连接内没有设法获得一次。

更新（2013 年 7 月 5 日：我忘记了该服务器还有另一个网络连接。这是几周前连接的。看起来这是这个问题的根本原因。

4

4 回答 4

2
  1. 读这个。
  2. 您可以定义要在连接字符串中使用的网络库。dbmssocn是我的首选。
  3. 也许将端口添加到连接字符串。

当您使用 IP 地址时，指定端口号并为其提供网络库，这就像我认为的“非常非常具体”。

查看通过 IP 地址连接的示例。

于 2013-06-19T13:47:51.017 回答
0

检查您的开发人员是否始终使用 atry/finally或usingblock 进行连接。很多时候你会看到这样的代码：

SqlConnection con = ... ;
con.Open();

// ... use the connection ...

con.Close();

那个代码是错误的。如果在该代码中间发生异常，con.Close();则永远不会执行该行。这会导致连接保持打开状态，如果这种情况发生得足够频繁，您将最大限度地增加服务器上允许的活动连接数，将自己锁定在服务器之外，并获得与您发布的类似的异常跟踪。

相反，您需要始终使用using块或try/来包装您的连接finally：

using (SqlConnection con = ... )
{
    con.Open();

    // ... use the connection ...
}

请注意，我什至不需要在con.Close()这里调用，因为 using 块为我处理了它。另一种选择：

SqlConnection con = ... ;
try 
{    
    con.Open();

    // ... use the connection ...
}
finally
{
    con.Close();
}
于 2013-06-19T16:36:09.763 回答
0

服务器和客户端都通过两个独立的网络连接。当我通过网络 A 发送连接请求时，似乎 SQL Server 可能会通过网络 B 回答它。

在 Windows 中正确设置了网络优先级（A 高于 B）。

解决我的问题是更换服务器上的两条网线。现在不再有超时，一切都按预期工作。服务器在主板上有两个连接器，但似乎忽略了 Windows 的优先级设置。

网络 B 在 SQL Server TCP 配置中被禁用，因此无论如何都不应该使用它。这对我来说是一种奇怪的行为，因为我找不到可能发生这种情况的原因。

于 2013-07-05T13:54:41.667 回答
0

很难说这是从哪里来的，但是在连接字符串中使用端口而不是命名实例是一个选项吗？

如果您使用命名实例，第一个请求会转到目标系统上的 SQL Server Browser（在端口 1434 上运行）以获取与命名实例关联的端口。只有这样才能真正连接到指定的端口。如果您直接使用该端口，则可以消除这种往返，如果您在任何地方都使用该端口，您还可以通过关闭 SQL Server Browser 来减少攻击面。

于 2013-06-19T16:28:40.443 回答