`
wsql
  • 浏览: 11716448 次
  • 性别: Icon_minigender_1
  • 来自: 深圳
文章分类
社区版块
存档分类
最新评论

浅谈数据库连接

 
阅读更多

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

我们经常会遇到很多连接问题,同时程序员往往也认为连接数据库只需要简单地连接→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服务器和客户端服务器移到物理上比较近、中间网络设备比较少的网段。修改连接配置,换一种网络协议。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics