原文:浅谈数据库连接

必须澄清，虽然文章是我总结整理的，但是很多知识的确不是我能研究分析得出来，通过听培训、看书、实践所总结得出，一方面为了给自己备用，以便以后出现问题能解决，另一方面也希望遇到相同问题的朋友能从中得到一些启示。所以文章里面的知识可能会在很多地方都出现。

我们经常会遇到很多连接问题，同时程序员往往也认为连接数据库只需要简单地连接→openconnection→操作→close，但是一个简单的连接动作，背后往往带有很多东西，充分理解，会对开发及管理有很大的帮助，毕竟连不上服务器其他一切都是白搭：

首先，从开发层面，要保证数据库连接的稳定性：

原因一：数据库连接是很“重”的操作，消耗资源很多

在常见的C/S模式中，简单的连接操作背后潜藏如下操作：

1、客户端与远程服务器的监听程序（listenerprogram)建立联系。

2、监听程序要么创建一个进程或线程来执行数据库核心程序，要么直接或间接地把客户请求传递给已存在的服务器进程，取决于服务器是否共享服务器。

3、为每个session建立新环境，跟踪它们的行为。建立前还要做账号密码匹配。有可能DBMS还要执行登录触发器，初始化存储过程和程序包（如果它们是第一次被调用的话）。

4、客户端进程和服务器进程之间要完成的握手协议。

正因为如此，连接池技术才尤为重要。

原因二：程序（包括存储过程）和数据库之间的交互也要开销：

即使连接建立但未中断，程序和DBMS之间的上下文切换也有代价。对此，如果DBMS支持数据通过数组传递，应该毫不犹豫使用它。

一些初级程序员（没有鄙视的意思），会很简单地在每个插入中连接、断开数据库，如果有大量数据（过万已经会出现问题），就容易耗尽服务器资源。曾经听过一名微软工程师说他们去服务客户的一个例子，一个手机流水线，但是开到第五条线的时候就卡得不行，实在开不了第六条线。后来发现，是编程的时候把循环放在连接的外层，每循环一次，就要连接、断开一次。造成严重的负载。后来把循环放到连接里面，可以开到上百条生产线。可见连接的重要性。

然后，从数据库管理层面：

数据库客户端应用使用数据库服务时：

第一步、在SQL Server上建立一个连接。如果双方都在一台机器上，就是本地连接。如果不在一台机器上，就需要通过网络层。

第二步、客户端需要告知SQL Server自己的身份。然后SQLServer需要认证（Authentication）是否合法，从而赋予预设的授权（Authorization）

以上的工作有客户端数据驱动程序（ODBC、OLE DB、NativeClient、JDBC等）和SQL Server交互完成，成功以后客户端用户才能开始访问数据。

在连接过程中，如果遇到问题，客户端驱动程序一定会抛出错误信息。让我们找到错误的原因：

1、  客户端驱动没能找到用户指定的SQL Server：如

SQL Server doesn’t exist or access denied

虽然说是不存在或者访问被拒绝，但是其实意味着：指定的SQL Server没找到

2、  SQL Server已经找到，甚至连接已经建立，但是因为某种未知原因，连接异常中断：

[DBMSSOCN] General network error. Chack your networkdocumentation.

或者

A transport level error occurred when sending a request(provider:TCP provider error: 0 an existing connection was forcibly closed bythe remote host)

这种错误可能发生在连接过程中的任何时候，包括建立初期和客户端指令运行时，原因有很多，比较难简单处理。

3、  用户认证失败，SQLServer认为连接使用了一个非法用户而拒绝：

Login failed for user “Null”

“消息 18456，级别 14，状态 1，服务器 <computer_name>，第1行”

“用户‘<user_name>’ 登录失败”

4、  认证过程中遇到错误，认证动作异常终止

Failed to generate SSPI context

这种错误发生在一些原有权力访问的SQLServer用户身上。用户明明有访问权力。但是在某些机器上，某些时段无法连接。

有时候错误会间歇发生甚至会自动消失。

下面来详细说明一下：

一、协议的选择与别名：

连接数据库首先要启用网络协议，无论是本地连接还是网络连接。

SQL Server可以同时侦听多种协议处理请求。客户端（这里的客户端是多种的，不是特指前端应用程序）会选择一个协议连接SQLServer。如果不知道SQLServer正在侦听哪个协议，可以配置客户端按顺序尝试连接：

SQLServer目前常用的有3个：Shared Memory、TCP/IP和Named Pipe

Shared Memory：最简单的协议，没有特殊配置

         由于该协议仅能连到同一台计算机上运行的SQLServer。索引对应大多数连接是没有办法使用的。但可以在调试其他协议的时候进行故障界定工作，以确保连接问题是和网络层有关，还是和SQLServer自己有关系。同时，它也是最快的协议。

TCP/IP：在Internet上广泛使用的通用协议

         包括路由网络流量的标准，并提供高级安全功能，是商业中最常用的协议。也是SQLServer最常用的网络协议。

Named Pipe：是为局域网开发的协议

         内存的一部分被某个进程用来向另一个进程传递信息，因此一个进程的输出就是另一个进程的输入。第二个进程可以是本地的（与第一进程处于同一台计算机上），也可以是远程的（位于联网的计算机上）。如果你使用过命名管道进行编程，会发现它是利用标准的Win32文件系统API函数（如ReadFile和WriteFile）来进行数据的收发。与系统基层网络传送协议无关。基本过程如下：

         （1）、SQLServer服务器使用CreateNamedPipe函数创建命名管道并对其进行监听。

         （2）、客户端使用CreateFile和WriteFile函数试图连接到服务器的命名管道。

所以：

1、  命名管道不是一个基层网络协议。即使使用命名管道，也要配置TCP或其他基层网络协议保证客户端和SQLServer服务器之间的网络连通性。

2、  命名管道是一个要通过系统认证的协议。

因为它首先访问服务器的IPC$共享。这一步必须通过Windows认证。才能连到SQLServer监听的管道上。这是使用命名管道的最大好处，直接利用Windows内置的安全机制。

应该根据不同要求选择协议，如果没有特殊原因，建议先考虑TCP/IP协议。

连接决定使用哪种协议？

首先、由服务器的网络协议配置控制。如果没启用，那么就没办法使用。

其次、客户端也能设置协议顺序。

最后、客户端可以设置某个SQLServer服务的别名，指定其连接方式，同时客户端也可对上次成功连接的缓存中使用连接方式。

1.1、       服务器网络配置：

网络配置在SQL Server配置管理器（Configuration Manager）的Network Configuration

配置的结果其实是存放在注册表：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MicrosoftSQL Server\MSSQL.X\MSSQLServer\SuperSocketNetLib下的各个项目里。可以从这里直接修改（但不建议）。修改需要重启服务。

重启后，检查SQLServer的errorlog进行确认。

Shared Memory 正常启动后信息类似如下：

Xxxx-xx-xx xx:xx:xx.xx Server Server local connectionprovider is ready to accept connection on [\\.\pipe\SQLLocal\MSSQLSERVER].

Named Pipe正常启动后可以看到：

Xxxx-xx-xx xx:xx:xx.xx Server Server named pipe provider isready to accept connection on [\\.\pipe\sql\query].

TCP/IP正常启动可以看到：

xxxx-xx-xx xx:xx:xx.xx Server Server is listening on [‘any’<ipv4> 1433].—侦听服务器上所有IP地址上的1433端口

1.2、       SQL Server Browser的作用：

如果客户端使用TCP/IP协议连到SQLServer，就必须指定SQLServer正在侦听的端口。如果使用NamedPipe，就必须指定管道名字。在2000之前，一台计算机只能装一个实例。所以SQLServer总之侦听1433端口，当2000引入多实例是，只有默认实例可以使用这个端口。对于命名实例，每次重启绑定的端口可能不一样，而用户只知道数据库服务器名字和实例名，为此，SQLServer产品组开发了一套SQL Server解析协议（SSRP），用于侦听UDP1434端口。该侦听器服务由一个SQLServer实例兼任。任何一个客户端要访问这台服务器上的SQL
Server实例时，都会先询问UDP1434端口，然后由SSRP协议告诉客户端本台服务器上所安装的SQLServer实例的端口号和管道名字。

但在2003年出现的Slammer病毒导致了这个组件发出大量的网络包，是SQLServer相关的迄今为止危害最大的病毒。所以从SQLServer2005引入了SQL Server Browser服务替代原有机制。

SQL Server Browser使用SSRP侦听UDP端口，并接受未经身份验证的请求。为了减少恶意攻击，SQLServer浏览器将设置在低级特权用户的安全上下文中运行。让被攻击的几率降到最低。可以将新建用户加入SQLServerXXXSQLBrowser$这个本地组。权限如下：

l  拒绝通过网络访问该计算机

l  拒绝本地登录

l  拒绝以批处理作业登录

l  拒绝通过“终端服务”登录

l  作为服务登录

l  读写与网络通信（端口和管道）相关的SQL Server注册表项。

SQL ServerBrowser启动后，它会启动并使用UDP 1434端口。此时会读取注册表，识别计算机上所有SQLServer实例，并注明使用的端口和命名管道。当有多个网卡时，会启用第一个遇到的端口。

         如果SQL Server Browser服务不运行，而你提供了正确的端口号或命名管道，仍然可以连接SQLServer如果默认实例在1433端口上运行，可以使用TCP/IP连接到默认实例。但是以下连接无效：

l  未完全指定所有参数（例如端口和管道名称）的情况下，组件尝试连接到命名实例。

l  生成或传递其他组件随后要用来进行重新连接的服务器/实例信息的组件。

l  未提供端口号或管道就连接到命名实例。

l  在未使用TCP 1433端口的情况下，将DAC连接到命名实例或默认实例。

l  枚举SSMS、企业管理器或查询分析器中的服务器。

如果应用程序通过网络访问SQLServer，要停止或禁用SQL Server Browser，必须为每个实例分配一个腾定端口号，然后在应用程序代码中指定该端口号。但还有以下问题：

l  必须更新和维护客户端应用程序代码。

l  如果服务器上的其他服务或应用程序占用了端口，会导致实例不可用。

如果报告：SQL Server doesn’texist or access denied，可以尝试指定端口，或管道名字，看能否连上，如果连上，是因为UDP 1434在网络中禁用了。需要防火墙或网关打开端口。要注意SQL Server Browser启动账号要有读写与网络通信相关的SQL Server注册表项的权限。如果权限不够，不会报错，也不会返回错误信息。

1.3、       客户端网络配置：

应用程序都是通过加载SQL Server的数据驱动控件做SQL Server连接。目前有三种：

a.      MDAC（Microsoft数据访问组件）：

包括ODBC和OLE DB借口。主要是非.NET的应用服务。默认自带，但有可能需要更新版本。在命令行中运行：cliconfg.exe就可以配置MDAC访问组件的网络协议。

可以配置协议及先后顺序，还可以饿配置是否使用SSL（网络传输加密），是否尝试使用Shared Memory等。同样可以通过修改注册表得到效果。

b.      SQL Server Native Client：

是2005以后引入的用于OLE DB和ODBC的独立数据访问API。05自带9.0版本，08自带10版本。它将SQL Server OLE DB访问接口和SQL Server ODBC驱动程序组合成一个本机的DLL。除原有功能外，还提供新功能。用于创建新应用程序或增强现有应用程序，使其能在SQLServer2005中引入新功能。如MARS、UDT、查询通知、快照隔离和XML数据类型支持。

如果使用C#等语言，且要使用05、08中新功能那么应当使用SQL Server的.NET Framework数据访问接口，是VS2005的.NET Framework一部分。为2005、2008提供最强大的数据访问组件。对于新功能，应该选择使用SQL Server Native Client。它和MDAC都支持使用行版本控制的已提交读事务隔离，但使用它支持快照事务隔离。

这个组件默认是不安装的。可以在安装时一起安装，也可以在安装文件的sqlncli.msi中单独安装。如果安装了，可以在SQL Server Configuration Manager中看到和配置。

c.      Microsoft JDBC Provider：是JAVA专用的。有专门的网络配置界面。

1.4、       客户端网络连接选择机制：

（1）      SQL Server自己有网络协议配置选项，决定SQL Server侦听哪些协议。如果没开启，则连接请求不会有反应。

（2）      如果有多个实例，每个端口和管道名称都不一样。SQLServer Browser通过读取注册表信息，能够知道本服务器上所有实例的网络配置信息。当客户端连接时，会先通过UDP1434向SQL Server Browser通信。这种机制是网络配置可以向客户端透明。

（3）      客户端的数据库连接组件上可以配置候选的网络协议，及候选优先级。

当有多个协议时，使用顺序如下：

1.      在连接字符串（Connection String）中指定

a.      Server关键字：Server=[protocol:]Server[,port]

如指定命名管道：np:Myserver\MyInstance

b.      Network关键字：Network=dbmssocn

两种方法只能选其一。

2.      客户端别名：

如果指定了别名，就会去TPC/IP找别名这台服务器，不成功就直接报错，不会尝试其他网络协议。

3.      寻找相应数据驱动程序的”LastConnect”注册表记录：

在注册表中会维护一组LastConnect记录，记录上次连接的网络配置。如果1、2步不成功，将会使用这里的配置。如果本次不成功，数据驱动程序会改试方法4

4.      按照数据库驱动程序的网络配置优先级选择网络协议，询问SQL Server Browser动态得知端口号或管道名字。当所有配置都不成功时，连接才报告失败。

二、连接失败检测步骤——命名管道

Windows中，进程间通信机制有邮槽、管道和套接字等。就管道而言，有命名管道和匿名管道。命名管道通过进程间通信（IPC）机制实现通信。进行单向或双向数据通信。

SQL Server命名管道工作原理：

         首先在服务器上创建一个命名管道并监听，然后客户端连接这个管道进行对话。

1.      命名管道的名称：

才有UNC格式标识命名管道：\\server\Pipe\path_name

\\server部分：指定命名管道所在的服务器，多用.来代表正在运行的本地服务器。

\pipe: 是一个固定的“硬编码”字串，表明管道协议。

\path_name：管道名称，可以是多级目录。一般监听的有：\sql\query。

例子：

默认实例：\\.\pipe\sql\query

命名实例：\\.\pipe\MSSQL$instancename\sql\query

2.      配置或查看SQL Server监听的命名管道：

使用SQL Server Configuration Manager为每个实例配置格子的网络协议：

3.      验证SQL Server是否监听了命名管道：

需要检查errorlog：

                   客户端的命名管道配置：

                   一般不会特殊配置，默认开启，但建议检查

1.      客户端网络实用工具——MDAC数据库接口：

Cliconfg.exe，如图，必须保证SQLServer监听的命名管道名称和客户端连接的默认管道名称是一致的。

2.      SQL Server ConfigurationManager——SQL Server Native Client：使用下图配置

3.      善用客户端SQL Server别名：

别名是在客户端配置，不能在服务器设置一次就可以的。可以使用SQL Server Configuration Manager或者SQLServer客户端网络实用工具来管理：

命名管道连接问题的解决步骤：

1、  使用【服务器端网络实用工具】检查命名管道配置并确认SQL Server已经监听了命名管道协议。

2、  使用【客户端网络实用工具】检查客户端的连接协议配置，确保启用了命名管道。客户端和服务器的默认管道名称需要和服务器监听的一致。

3、  检查网络连通性。要能ping通服务器的IP及服务器名

4、  检查客户端是否能够通过服务器的Windows认证：

Net view \\servername

Net use \\servername\IPC$

如果两条命令出错，则表明有访问SQL Server服务器权限上的问题。

5、  确保客户端登录账号有权限访问SQL Server。

一些常见的连接问题：

一、多数是客户端没找到命名管道服务器即SQL Server

[Named Pipes]SQL Server does not exist or access denied.

[Named Pipes]ConnectionOpen(Connect()).

解决方法：

（1）、检查网络连通性，如ping

（2）、检查SQLServer服务器端和客户端的命名管道配置

二、访问权限：

Login failed for user ‘NULL’或Login failed foruser anonymous

表明连通没问题，只是命名管道访问服务器权限上的问题。不要忘记IPC$共享，没有权限访问IPC$就无法使用命名管道。可以运行：

net use \\servername\IPC$ 来测试

三、访问权限2：

Login failed for user ‘User123’

表明该用户没用权限访问服务器的资源或者SQLServer。不是连接问题，而是权限问题

                   为了避免上面问题：

（1）      建立连接后，如何查看使用的协议？可以在SSMS中运行：

Net_library说明了协议，如果为LPC，代表使用Shared Memory

（2）      除了使用SSMS之外，另一个就是ODBC数据源。运行：ODBCAD32.exe。

使用该工具尝试连接到SQL Server的系统DSN。如果报错，证明连接有问题。报错的时候会返回错误号，可以使用“net helpmsg 错误号”来查询。

三、连接失败检查步骤——TCP/IP

TCP/IP协议有两个基本东西：IP地址和端口号。

添加TCP/IP时，需要重启服务器。

对于端口号，可以在配置工具中点解TCP/IP，然后选择属性，可以看到其侦听的端口号：

只要端口未被其他进程占用，就可以改变这个端口号。一般高于5000的端口号都可以使用。从1024~5000的端口号经常会被系统和程序占用，所以不建议取这个范围。可以从这个连接查看Windows系统使用的端口号：

http://support.microsoft.com/?id=832017

或者可以使用netstat命令查看侦听的端口：netstat –an可以看到系统所有使用中的端口号。

客户端TCP/IP协议配置：

客户端默认开启TCP/IP。也可以使用cliconfg.exe来配置。如果默认实例不是1433，则需要在Default port做相应改变。也可以使用别名指定服务器的端口。也可以使用动态端口，如图：

TCP/IP连接问题的解决步骤：

步骤1：验证SQLServer是否确实监听了TCP/IP协议：

                   验证协议也需要查看errorlog。如果看到下面一样，证明已经监听了TCP/IP

如果发现没有监听，可以使用服务器网络配置工具【svrnetcn.exe】配置。此工具需要下载。

步骤2：验证服务器监听的TCP/IP端口和客户端配置的默认值或别名中指定的值一致：

                   除了配置一样之外，客户端连接的默认端口需要和SQLServer服务器监听的一致。如果有别名，需要仔细查看其指定的端口是否正确。

步骤3：检查网络连通性：

                   要确保不仅ping同SQLServer服务器的IP地址，也要能ping通sqlserver服务器的名称。如果名字ping不同，说明DNS或WINS服务器配置有问题，可以在HOSTS文件（system32\drivers\etc下）中手工加入IP地址和服务器对，如：

169.254.173.244 MySQLServer

步骤4：使用telnet命令检查SQLServer监听的端口：

                   要验证SQLServer监听的端口，可以使用telnet命令，假设IP为192.168.1.1，端口为1234，可以使用：telnet192.168.1.1 1234。如果成功，那么会显示一个光标在闪的黑色屏幕。如果不成功会返回错误信息。

步骤5：检查登录用户的SQLServer访问权限：

                   和命名管道一样，必须确保客户端登录账号有权限访问SQL Server。

为了减少配置错误，可以使用以下措施：

1、  配置多个静态端口：

只需使用服务器网络配置工具在TCP/IP协议属性中输入多个逗号分隔的端口号就可以了。虽然监听多个端口的意义不大，如果认为有网络性能问题，还不如增加网卡，这样比提升多端口要好得多。

2、  TCP/IP端口绑定失败：

如果静态端口被占用，会出现以下错误信息：

Server SuperSocket Info: Bind failed on TCP port 1433.

对此，可以指定其他端口，或停用一些服务再重启SQLServer服务。如果想查看什么程序占用端口，可以使用PortQry.exe（需下载）获取。使用说明：

http://support.microsoft.com/default.aspx?kbid=310099

例子：protqry –n Myserver –p TCP –e 1433

3、  检查连接使用的协议：

通过SSMS执行下面语句即可：

4、  如何访问防火墙后面的SQLServer：

必须配置防火墙以允许从*ANY*（大于1024的端口）到1433的通信量，及从1433到*ANY*的通信量。

具体说明可以参考技术文档：

http://support.microsoft.com/?id=287932

5、  在ManagementStudio中指定连接的协议和端口：

可以强制使用TCP/IP连接服务器指定端口。

6、  其他：

在以上步骤都不成功的时候，使用Network Monitor工具捕捉网络包来分析。它可以获取一些其他手段找不到的原因。详细参考：

http://support.microsoft.com/default.aspx?kbid=148942

四、一般性网络错误（GeneralNetwork Error）

1、  可能发生在连接生命周期的任何一步：

这个问题和“SQL Server doesn’t exists or access denied”有本质区别，后者是连不到SQLServer服务，但前者是已经找到SQLServer服务，但连接在建立、传送客户端查询指令，或收到SQLServer返回的数据结果集的任何一步发生了异常中断。此时要检查错误的详细信息：

2、  一般只是偶尔发生，或者集中在某个时间段发生，而且很可能会自动消失：

如果时有时无，就需要抓一组Network Monitor的日志，甚至是Windows的内核跟踪，总能定位问题。

3、  问题产生的可能原因非常多：

常见原因：

1.      服务器的负荷：

如果服务器负荷高，有可能在网络中会发出很多RESET包，在超过重试次数后，客户端会中断连接，抛出GNE。这类问题会影响所有连接，甚至在SQLServer服务器上的本地连接。

2.      繁忙的应用服务器没有使用连接池：

在三层应用结构中，中间层应用服务器会同时接受大量的数据库登出登入请求，如果没有使用连接池，SQLServer需要维护连接的负担会非常重。可能会有少数连接照顾不过来，容易遇到GNE。如果开启连接池，负载就能大大降低，问题也就可以解决了。

3.      网络传输层问题：

由于数据库经常要传输大量的结果集，网络层比较繁忙。如果两台计算机之间的网络有频繁重传现象，或者特定类型的网络包被某个网络设备（网关、路由、防火墙等）修改或丢弃，那么GNE出现几率比较高。这类问题只发生在特定的一组SQLServer服务器和客户端之间。同一个SQLServer可能有写客户端没有问题，有些有问题。跨网段或跨子网的客户端问题比较多。

4.      Windows操作系统层面问题：

SQLServer的连接由Windows建立和维护，所以Windows层面的许多行为会影响SQLServer的连接稳定性。当数据库、网络很繁忙时，Windows为了维护自身安全，会有意拒绝一些网络请求。造成误杀。

5.      不恰当的系统设置：

有时候会从安全性角度考虑，修改一些系统设置，但是过于严厉的话会导致SQLServer连接的不稳定。常见的是TCP设置，在

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters下。

SQLServer层的设置也有两个地方可能引起GNE错误，都在sp_configure中：

l  Priority boost：SQLServer以高优先级启动。一般情况下不推荐设置。

l  Lightweight pooling：会使SQLServer切换到纤程模式计划。会影响SQLServer的运行模式，有时会带来GNE副作用。由于大部分情况下不会带来明显的性能提高，所以不建议使用。

6.      防毒软件和防火墙：

这些软硬件有可能导致误杀现象。

7.      网络设备：

有些应用会长时间连接数据库，几乎从来不登出。如果没有操作请求，连接会长时间处于空闲状态。对于这样的TCP连接，SQLServer会每隔30秒做一次KeepAlive握手。确保连接是否有效。如果客户端对此没有反馈，SQLServer会中断这个连接。当客户端下次使用时，就会收到GNE。有些网络设备会在空闲30~40分钟后直接断开连接。也会直接导致GNE。

8.      错误的网卡配置：

在集群服务器上，至少有两块网卡。如果心跳线也能访问公共网络，就容易出现GNE。

4、  GNE情况很多，但是还是可以做以下的操作，减缓或者解决：

1．  分析网络拓扑结构，确定网络的可靠性

2．  涉及SQLServer服务器和客户端服务器做全面健康检查，确认它的工作正常。

l  Windows日志中不可以有明显的错误

l  CPU不可以长时间100%

l  Windows不可以有系统缓存及内存方面的问题。

l  SQL Server的errorlog里不可以有明显的错误，重点错误是：AV、内存、磁盘、17883/17884

l  SQLServer不可以发生大范围、涉及100个以上的连接阻塞问题。

l  检查sysprocesses系统视图，不可出现经常有大量连接处于runnable/running状态。

3．  按照下面方式配置SQLServer服务器和客户端服务器：

（1）、禁用RSS：

找到注册表：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableRSS，将其设为0.

（2）、禁用TaksOffload：

找到注册表：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DisableTaskOff，将其设为1

（3）、禁用TCP Chimney：

输入：netsh in tip set chimney DISABLED

（4）、禁用TCPA：

找到注册表：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableTCPA，将其设为0.

（5）、重启机器使设置生效。

（6）、将所有有关系的机器Windows升级到最新的更新版本。网络设备firmware升级到最新。

（7）、检查SQLServer sp_configure里面priority boost和lightweight pooling是否被改动过。

4．  正确配置网络：

（1）、确认注册表：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters下都是默认配置

（2）、再次确认没有配置网卡的Teaming。

（3）、在集群环境里，确认两块网卡配置正确。

（4）、确认网罗设备自动关闭Idle连接的功能已经被禁用。

（5）、暂时关闭防毒软件和防火墙。

（6）、如果可能，尽量将SQLServer服务器和客户端服务器移到物理上比较近、中间网络设备比较少的网段。修改连接配置，换一种网络协议。