好文章浅谈数据库连接

http://www.360doc.com/content/13/0531/09/11253639_289400176.shtml# 必须澄清，虽然文章是我总结整理的，但是很多知识的确不是我能研究分析得出来，通过听培训、看书、实践所总结得出，一方面为了给自己备用，以便以后出现问题能解决，另一方面也希望遇到

http://www.360doc.com/content/13/0531/09/11253639_289400176.shtml#

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

我们经常会遇到很多连接问题，同时程序员往往也认为连接数据库只需要简单地连接→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，服务器 ，第1行”

“用户‘’ 登录失败”

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’ 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服务器和客户端服务器移到物理上比较近、中间网络设备比较少的网段。修改连接配置，换一种网络协议。