SQLServer连接问题－TCPIP
出⾃：
TCP/IP的基本⼯作原理这⾥就不浪费⼝⽔了。现在这⽹络年代，谁不知道TCP/IP啊。不要跟我抬杠说你偏就没听说过TCP/IP阿，真是这样那你得⾃⼰去补补课了。
TCP/IP协议有两个基本的东西，⼀个是IP地址， 另⼀个是端⼝号。 在SQL Server上使⽤TCP/IP协议是⾮常简单的。⾸先要对SQL Server所在机器的⽹卡配置好TCP/IP协议并得到⼀个IP地址（通过静态指定分配或从DHCP服务器动态获得都⾏），接下来就需要通过SQL Server提供的⼯具做服务器端设置。
⼀、Microsoft SQL Server上的TCP/IP协议
在运⾏SQL Server 2000的服务器上，运⾏服务器端⽹络配置⼯具（运⾏即可调出）配置SQL Server监听TCP/IP协议即可，如图所⽰：
tcpip协议pdf在运⾏Microsoft SQL Server 2005/2008上的服务器上，配置TCP/IP协议需要在SQL Server配置管理器(Configuration Manager)⼯具下的Network Configuration下⾯。下⾯是这个⼯具的截屏。
其实，不论是SQL Server 2000还是SQL Server 2005/2008，配置的结果都是存放在注册表HKEY_LOCAL_MACHINE
\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.<InstanceID>\MSSQLServer\SuperSocketNetLib下⾯的各个项⽬⾥。不⽤管理界⾯，直接修改注册表也能达到⼀样的⽬的。
（要注意，如果你的机器上只有SQL Server 2000的默认实例，那么注册表所在位置会稍有不同，它是
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\SuperSocketNetLib.）
配置好⽹络协议以后，需要重新启动SQL Server服务，让修改⽣效。启动后，需要检查SQL Server的errorlog，确认这些协议都已经被正常开启。
Shared Memory正常启动，可以看到如下信息。
2009-04-12 10:04:27.92 ServerServer local connection provideris ready to accept connection on [
\\.\pipe\SQLLocal\MSSQLSERVER ].
Named Pipe正常启动，可以看到如下信息。
2009-04-12 10:04:27.92 ServerServer named pipe provideris ready to accept connection on [ \\.\pipe\sql\query ].
TCP/IP正常启动，可以看到SQL Server实例正在侦听的IP地址和Port号。例如：
2009-04-12 10:04:27.92 Server Server is listening on [ 'any' <ipv4> 1433].
--侦听服务器上所有IP地址上的1433端⼝。
或者：
2008-06-12 15:01:58.150 Server Server is listening on [ 172.30.30.80 <ipv4> 1433].
--只侦听指定的IP地址上（172.30.30.80）的1433端⼝。
这⾥也顺便回答⼀个⼩问题。 有些朋友问， 如果机器的IP地址改变，对SQL Server有没有影响， 需要作什么动作等。答案很简单， 重新启动SQL Server服务就可以了。SQL Server会⾃动监听机器的新IP地址，⽆需重新安装或配置SQL Server。
⼆、Microsoft SQL Server 2000监听的TCP/IP端⼝号
现在谈谈⼀个重要的配置即端⼝号。在服务器端⽹络配置⼯具中或者在配置管理器中选中TCP/IP协议，点击Properties按钮，就可以查看SQL Server侦听的端⼝号：
（SQL Server 2000服务器端⽹络配置⼯具）
（SQL Server 2005/2008配置管理器）
这⾥显⽰的就是SQL Server监听的TCP/IP端⼝。默认值为1433。SQL Server服务器将在该端⼝上监听并接受客户端的TCP/IP socket 连接请求。你可以改变这个默认值为别的端⼝号，只要该端⼝没有被系统或别的应⽤程序占⽤即可。⼀般说来⾼于5000以上的端⼝号码都可以随意使⽤，或者使⽤⼩于1024的操作系统或其他应⽤程序不使⽤的空闲端⼝。为什么不⽤1024⾄5000之间的端⼝呢？因为缺省情况下操作系统会把这个范围内的端⼝分配给服务或应⽤程序使⽤。为了避免潜在的端⼝冲突所以使⽤5000以上或1024以下的值。实际上不论那个范围，只需要是空闲的没使⽤的端⼝都可以。微软有⼀篇很好的技术⽂档详细讨论了Windows系统使⽤⼀些端⼝号，⽂档连接如下：
Microsoft Windows服务器系统的端⼝要求
或许你会问，有没有⽅法查看SQL Server监听的端⼝啊？有的，可以使⽤netstat命令。在DOS窗⼝下运⾏“netstat -an”命令即可列出系统所有使⽤中的端⼝号，当然SQL Server监听的端⼝也在其中了。下⾯是从“netstat -an”命令的输出中摘取的有关SQL Server的端⼝号部分：
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:1433 0.0.0.0:0 LISTENING
TCP 169.254.173.244:1433 169.254.173.244:3952 ESTABLISHED
UDP 0.0.0.0:1434 *:*
上⾯列出的1434端⼝是⽐较有趣的⼀个端⼝，详见后⾯的内容。
SQL Server⽀持⼀台机器安装多套实例，即默认实例和命名实例。对于默认实例，缺省侦听的IP端⼝是1433。如果你把默认实例的监听端⼝改为⾮1433端⼝，那么客户端就有可能连接不上SQL server默认实例。这个时候必须使⽤客户端⽹络⼯具指定SQL Server侦听的IP 端⼝或创建⼀个指定IP端⼝的SQL Server别名。关于客户端⽹络⼯具在下⾯会具体讲。
三、TCP/IP静态端⼝，动态端⼝，SQL Server Browser和UDP 1434端⼝的概念
⾸先讨论1434端⼝。1434端⼝是⽤来⼲吗的呢？
我们都知道SQL Server⽀持多个实例，缺省的SQL Server实例使⽤默认的1433端⼝。对于其余的命名实例(Named Instance），每次启动所绑定的端⼝号可能都不⼀样。让每个⽤户都去记住SQL的端⼝号是不可能的。⼀个数据库普通⽤户只会知道数据库服务器的名字和实例名。那么怎么根据服务器名和实例名到相应的端⼝号呢？SQL Server 2000的时代，产品组开发了⼀套SQL Server解析协议(SSRP)，⽤于侦听UDP 1434端⼝。当SQL Server 2000客户端Net-Library连接到SQL Server 2000实例时，仅需要运⾏该实例的计算机所在的⽹络名和该实例名（如MYSQLSrv\inst1）。当应⽤程序请求连接SQL Server服务器时，客户端⽹络库发送⼀个⽹络包到SQL Server服务器的1434端⼝。所有运⾏SQL Server 2000实例的计算机都监听此端⼝。服务器收到查询⽹络包时将返回⼀个包含服务器上运⾏的所有实例监听信息的数据包。对于每个实例，该数据包报告该实例正在监听的服务器Net-Library和具体⽹络地址。客户端应⽤程序根据返回的⽹络地址进⾏连接。 举个具体的例⼦，对于命名实例，该返回的⽹络包中包含了SQL Server服务器正在监听的TCP/IP端⼝，客户端应⽤程序得到端⼝号后才能和SQL Server建⽴连接。
这个设计理念本⾝是挺好的。但是在2003年，⼀个叫Slammer的病毒利⽤SSRP功能组件⾥的⼀个bug，诱导SQL Server服务在UDP端⼝发出⼤量⽹络包，从⽽导致了⽹络阻塞，并且使数据库服务瘫痪的严重后果。这个病毒是和SQL Server相关的迄今为⽌危害最⼤的病毒。为了避免这类悲剧事件再次发⽣，SQL Server 2005引⼊了SQL Server Browser服务来替换原有的机制。
SQL Server browser⽤SQL Server解析协议(SSRP)侦听UDP端⼝，并接受未经⾝份验证的请求。为了防⽌恶意⽤户利⽤这个服务攻击SQL Server服务器，SQL Server浏览器可以设置在低特权⽤户的安全上下⽂中运⾏，将受到恶意攻击的⼏率降到最低。可以将⼀个新建⽤户加⼊SQLServerXXXXSQLBrowser$这个本地组⾥。并且需要通过使⽤SQL Server配置管理器更改登录帐户。SQL Server浏览器的最⼩⽤户权限如下：
拒绝通过⽹络访问该计算机
拒绝本地登录
拒绝以批处理作业登录
拒绝通过“终端服务”登录
作为服务登录
读取和写⼊与⽹络通信（端⼝和管道）相关的SQL Server注册表项
通过这样的设计，可以隔离恶意⽹络攻击对SQL Server服务本⾝的影响，并且通过限制SQL Browser登录⽤户权限的⽅法，限制了万⼀SQL Browser受到攻击，对整个服务器的影响。
启动SQL Server Browser后，它将启动并使⽤UDP 1434端⼝。SQL Server浏览器将读取注册表（所有
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\MSSQLServer\SuperSocketNetLib下的记录），识别计算机上的所有SQL Server实例，并注明它们使⽤的端⼝和命名管道。当⼀台服务器具有两个或多个⽹卡时，SQL Server浏览器会为SQL Server返回其遇到的第⼀个已启⽤的端⼝。
当SQL Server客户端请求SQL Server资源时，客户端数据驱动程序将使⽤1434端⼝向服务器发送⼀条UDP消息。SQL Server浏览器将会应请求实例的TCP/IP端⼝或命名管道名称。然后，客户端数据驱动程序将使⽤所需实例的端⼝或命名管道向服务器发送请求来完成连接。
当SQL Server Browser服务不运⾏时，如果您提供了正确的端⼝号或命名管道，仍可以连接到SQL Server。如果SQL Server的默认实例在1433端⼝上运⾏，则可以使⽤TCP/IP连接到此默认实例。
但是，如果SQL Server Browser服务未运⾏，则以下连接⽆效：
在未完全指定所有参数（例如TCP/IP端⼝或命名管道）的情况下，组件尝试连接到命名实例。
⽣成或传递其他组件随后要⽤来进⾏重新连接的服务器/实例信息的组件。
未提供端⼝号或管道就连接到命名实例。
在未使⽤TCP/IP 1433端⼝的情况下，将DAC连接到命名实例或默认实例。
枚举SQL Server Management Studio、企业管理器或查询分析器中的服务器。
如果应⽤程序通过⽹络访问SQL Server，若要停⽌或禁⽤SQL Server Browser服务，必须为每个实例分配⼀个特定端⼝号，并在客户端应⽤程序代码中指定该端⼝号。但此⽅法存在如下问题：
必须更新和维护客户端应⽤程序代码才能确保它连接到正确的端⼝。
如果服务器上的其他服务或应⽤程序占⽤了您为每个实例选择的端⼝，则会导致SQL Server实例不可⽤。
所以SQL Browser这个服务做的事情虽然很简单，但对正常的客户端连接⾮常重要。如果某些客户端连不上SQL Server，报告“SQL Server doesn't exist or access denied”，可以尝试指定端⼝，看看能不能连上。如果这样能够连上，⼀般是因为UDP 1434在⽹络上被禁⽤了，需要在防⽕墙或者⽹关上打开这个端⼝。
SQL Browser本⾝很少出现问题。不过由于其设计⽐较简单，⼀共只有4个线程在接受SSRP的包（2
个给IPv4，2个给IPv6）。因此⼀旦这些线程都因为异常⽽终⽌的话，可能会出现SQL Browser服务运⾏正常但是连接命名实例有问题的情况。这个时候你会在Windows的事件⽇志⾥看到以下错误：
The SQLBrowser processing of requests against a particular IP address has encountered a critical error. Processing of requests on this address has beenhalted(event ID 14)
微软已经有发布了⼀个补丁程序来解决这个问题，参见：
另外需要注意的是SQL Browser启动账号要有读取和写⼊与⽹络通信（端⼝和管道）相关的SQL Server注册表项
（HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\MSSQLServer\SuperSocketNetLib）的权⼒。如果注册表读不到，SQL Browser不会报错，但是就不告诉客户端想要的port和pipe的信息，也会导致客户端连不上。
再来讨论静态端⼝。本⽂⼀开头提及如何修改SQL Server监听的端⼝。 如果你配置的端⼝是⾮0值那么就是静态端⼝了。也即是我们指定了⼀个静态的端⼝号，SQL Server将在该端⼝上监听。这对于默认实例和命名实例都是⼀样的。只是对于默认实例，如果端⼝不是1433，那么得在客户端使⽤⽹络配置⼯具指定缺省连接端⼝或创建SQL别名来进⾏连接。⽽对于命名实例则不⼀样。你可以指定任意端
⼝值。只要SQL Server在该端⼝进⾏监听，那么客户端就能够通过1434端⼝查询出该命名实例的端⼝值⽽进⾏连接。
另外，万⼀指定的端⼝已经被占⽤时，SQL Server⼜会怎么办呢？ 对于默认实例，SQL Server⼲脆就放弃监听TCP/IP协议并在⽇志中记录“不能监听TCP端⼝”类似的信息。⽽对于命名实例则聪明⼀些。SQL Server命名实例会⾃动选择下⼀个空闲的端⼝来监听。
如果把SQL Server监听的端⼝设为0⼜会如何？这个问题⽐较有趣。事实是，当设为0时，⽆论是默认实例还是命名实例，SQL server都理解为需要动态配置监听的端⼝。动态配置的意思是，它们都会⾃动选择⼀个系统空闲的端⼝进⾏监听。但记住，对于默认实例，如果选择的端⼝不是1433的话，嘿嘿，你得需要在客户端使⽤⼯具配置缺省连接端⼝或使⽤别名了。
动态配置端⼝是否意味着SQL Server每次重新启动后都会随机选择⼀个未⽤端⼝呢？这倒不是的。 当重新启动后，SQL Server将设法侦听之前使⽤的端⼝。如果SQL Server不能绑定到该端⼝，那么会动态地绑定到另⼀个空闲端⼝。
四。客户端的TCP/IP协议配置
⼤多数情况下在客户端你不需要进⾏配置，因为TCP/IP协议默认是启⽤的。和命名管道⼀样，可以使⽤客户端⽹络实⽤⼯具进⾏配置
TCP/IP协议。客户端应⽤程序都是通过加载SQL Server的数据驱动控件做SQL Server连接的。现在客户端数据驱动库主要有2种：
1．MDAC (Microsoft数据访问组件)
运⾏或从开始-->程序-->Microsoft SQL Server -->客户端⽹络实⽤⼯具即可调出。
客户端⽹络实⽤⼯具中左边是禁⽤的协议，右边的是启⽤的协议。如果右边没有TCP/IP协议，则点击Enable按钮启⽤它。 选中TCP/IP后点击属性（Properties）按钮即可查看客户端连接的缺省的TCP/IP端⼝。缺省情况下1433（参考图4）。如果服务器默认实例（不是命名实例）监听的端⼝不是1433，那么你需要在这⾥把default port作相应的改变。当然你可以像在命名管道篇中介绍的那样创建服务器别名特别指定服务器的端⼝也可以。对于命名实例， 客户端⽹络库会利⽤UDP 1434端⼝查询服务器命名实例的监听协议信息。
可以在客户端配置SQL Server别名，以明确指定连接到SQL Server所使⽤的协议。注意在别名中可以指定端⼝，也可以使⽤动态查询端⼝功能。
当默认实例被配置为侦听⼀个⾮1433端⼝我们就可以通过配置默认端⼝或者别名来让客户端程序到默认实例。
配置的信息保存在注册表⾥，HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SuperSocketNetLib⼦⽬录下⾯。也可以直接改值，⼀样能达到效果。
2. SQL Server Native Client
在⼀台没有安装过SQL Server 2005或者2008的机器上，缺省不会安装SQL Server Native Client。在安装SQL Server 2008或SQL Server客户端⼯具时，将同时安装Microsoft SQL Server Native Client 10.0。如果计算机上还安装了SQL Server Native Client的SQL Server 2005版本，则SQL Server Native Client 10.0将与早期版本Microsoft SQL Server Native Client 9.0并⾏安装。
如果安装有SQL Server客户端⼯具，我们可以通过SQL Server Configuration Manager来配置客户端⽹络协议。配置的⽅法和MDAC 类似。
图5 - 5
如果没有安装这个⼯具，可能就需要直接修改注册表了。Microsoft SQL Server Native Client 9.0的信息存放在
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI9.0下⾯，Microsoft SQL
Server Native Client 10.0的信息存放在HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI10.0下⾯。
五。TCP/IP连接问题的解决步骤
步骤1：验证SQL Server是否真的监听了TCP/IP协议
为了验证SQL Server确实监听了TCP/IP协议，可以打开SQL Server Query Analyzer（查询分析器），然后运⾏如下命令：
p_readerrorlog
在结果栏，如果看到类似如下⼀⾏则表明SQL Server已经监听了TCP/IP：
2000-08-31 21:47:01.52 server SQL server listening on 169.254.173.244: 1433.
2000-08-31 21:47:01.52 server SQL server listening on 127.0.0.1: 1433.
2000-08-31 21:47:01.53 server SQL server listening on TCP, Shared Memory.
如果发现SQL Server没有监听TCP/IP协议，请使⽤服务器端⽹络配置⼯具（运⾏即可调
出）确认是否配置好SQL Server监听TCP/IP协议。
步骤2：验证服务器监听的TCP/IP端⼝和客户端配置的缺省值或别名中指定的值⼀致。
使⽤客户端⽹络实⽤⼯具检查客户端的连接协议配置，确保客户端启⽤了TCP/IP。当然，客户端连接的缺省端⼝需要和SQL服务器监听的⼀致。另外，如果有别名，需要仔细查看其指定的端⼝是否正确。如果客户端的别名设置错误，也会引起连接问题。
步骤3：检查⽹络连通性。
要确保不但能够ping通SQL Server服务器的IP地址，也能够ping通SQL Server服务器的名称。如果ping服务器名字有问题， 说明DNS或WINS服务器配置有问题， 可以在HOSTS⽂件（HOSTS⽂件在system32\drivers\etc⽬录下）中⼿⼯加⼊IP地址和服务器对如下：
169.254.173.244 MySQLserver
如果连ping IP地址都有问题， 那么得好好检查⽹络的配置包括硬件的连接。 在服务器上和客户端都使⽤ “ipconfig/all”命令检查服务器和客户端是否在同样的⽹络上。
步骤4：使⽤TELNET命令检查SQL监听的端⼝。
要验证SQL Server监听的端⼝， 可以使⽤TELNET命令。假设SQL Server的IP地址是192.168.1.1，端⼝是1234， 那么可以运⾏如下命令：
TELNET 192.168.1.1 1234
如果TELNET成功，那么结果将是⼀个只有光标在闪的⿊⾊屏幕。如果不成功， 那么你会得到出错的信息。需要根据这些出错信息继续排查问题。
步骤5：检查登录⽤户的SQL Server访问权限。
和命名管道⼀样，需要确保客户端登录（login）帐号有权限访问SQL Server。有关这⽅⾯内容请参考命名管道篇。
需要注意的是，如果你使⽤Windows系统帐号⽽不是SQL Server本⾝的login， 那么和命名管道⼀样，你需要有访问服务器资源的权限。如果该Windows系统帐号不能通过Windows的认证，⾃然不能访问SQL server.如果怀疑是Windows系统帐号的权限问题，可以使⽤SQL Server的login如sa尝试登录。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。