SQL更新后无法连接到服务器失败，最优先做一件事：不管客户端报什么错，先检查SQL服务进程是否真的在运行，服务状态正常后再去排查防火墙和端口，多数问题能直接定位。
sql 更新后无法连接到服务器失败，先从服务状态排查
更新后的故障和平时最大的不同在于,系统补丁或数据库补丁安装过程中通常伴随机器重启，机器重启后SQL服务如果没有自动恢复，远程连接当然会失败，而本机登录也可能提示服务不可用。
打开服务管理器,按下Win + R输入services.msc回车，在服务列表里找到SQL Server (MSSQLSERVER)，注意如果你的环境是命名实例，名称会是SQL Server (实例名)，查看“状态”列是不是“正在运行”，如果不是，右键选择“启动”。
更新后会出现一种特殊状态：服务显示“正在启动”但一直不结束，这种情况通常是旧版本数据库引擎和系统更新后的某些组件产生了兼容问题，或者数据库在恢复过程中需要较长时间，可以等待几分钟再刷新，若依然卡住，直接右键重启服务，重启后观察状态是否恢复正常。
还有一类容易被忽略的情况是依赖服务,对命名实例来说，SQL Server Browser服务负责解析实例名对应端口，如果系统更新后该服务被设为“禁用”或“停止”，客户端用主机名加实例名的形式连接就会失败，确认SQL Server Browser也处于运行状态，并把启动类型改为“自动”。
服务这一层排查完成后,再去重新测试连接，如果仍然报错，就进入下一步。
sqlserver连接服务器失败，多半是防火墙和端口卡住了
更新后连不上服务器,本机却能正常查询，这是最常见的报错场景，本机访问和远程访问走的是不同链路，本机能通，基本说明数据库引擎没大问题，问题出在远程访问链路。
先确认SQL Server实际监听的端口，命令行执行netstat -ano | findstr 1433，如果看到LISTENING，说明默认实例正在监听1433端口，无输出时可能使用的是命名实例动态端口，此时打开“SQL Server配置管理器”，依次展开“SQL Server网络配置”，选择对应实例，右键“TCP/IP”进入属性，查看“IP地址”选项卡中的端口配置，取消“动态端口”里的数字，在“TCP端口”填上固定端口如
1433，重启服务后端口就会稳定下来。
端口确认之后,检查防火墙规则，系统更新部署补丁时，有一定概率重置Windows防火墙的入站规则，导致之前放行的1433端口失效，打开“控制面板”－“Windows Defender防火墙”－“高级设置”，在“入站规则”里看看有没有名为SQL Server或包含1433端口的规则，状态是否为“已启用”，如果规则没了，点击右侧“新建规则”－“端口”－“TCP”－“特定本地端口”中输入1433，继续选择“允许连接”，应用到所有配置文件，完成创建，为了防止命名实例无法解析，可以顺带把1434端口也放行，这是SQL Server Browser服务使用的UDP端口。
云服务器用户还要额外检查一个位置：云平台的安全组，系统防火墙只是第一道关卡，安全组在虚拟机外部生效，个别云平台在实例更新或迁移地域后，安全组配置可能发生变更或关联到默认组，导致原来的放行规则失效，登录云控制台，找到对应实例的安全组策略，确认TCP 1433端口已对目标来源地址开放。
端口层面的检查完成后,使用telnet 服务器IP 1433测试通断，如果看到光标闪烁而不是报错，说明网络链路已经通了。
sql 远程连接失败排查方法：登录认证与实例名容易被漏掉
服务和端口都正常,客户端仍然报错，就要看报错类型了，网络层面连接失败，报错信息通常是“连接超时”或“无法打开服务器”，如果连接过程能到达SQL Server但登录被拒绝，报错会指向“用户登录失败”，错误码为18456，这类问题要从认证方式入手。
SQL Server实例在安装和更新后，认证模式默认是“Windows身份验证模式”，如果客户端使用SQL账号密码连接，更新前能用，更新后突然报18456，去服务器上打开SSMS，右键实例选择“属性”－“安全性”，确认“SQL Server和Windows身份验证模式”是否被选中，如果被改回了“Windows身份验证模式”，切换回去并重启服务。
认证模式没问题,继续检查登录名映射，有些登录名虽然有服务器级权限，但在具体数据库下没有映射到用户，报错信息里如果显示“无法打开用户指定的数据库”，打开SSMS展开“安全性”－“登录名”，双击对应登录名，在“用户映射”选项卡中勾选需要访问的数据库并分配身份，保存后再试。
连接字符串同样不可忽略,更新后应用配置中服务器地址如果写得太简单也会出问题，例如命名实例的写法应该包含实例名，写成主机名\实例名或者主机名,端口号，有些客户端工具在更新后将服务器地址自动改写，导致原本能连的配置失效，检查ODBC数据源、连接串中的Server字段，确认和实际实例名、端口保持一致。
这个阶段还需要关注一个容易被遮蔽的点：SQL Server的remote access选项，部分补丁更新后此选项被重置为0，会影响远程连接行为，在SSMS中执行sp_configure 'remote access'查看当前值，如果是0，改成1并执行RECONFIGURE后重启服务。
sql 更新后服务无法启动时，日志文件是可靠的线索
如果服务一直起不来,前面所有检查都无从下手，这时要看SQL Server错误日志，默认位置是安装目录下的MSSQL\Log\ERRORLOG，直接用记事本打开最新一个文件即可，也可以打开SSMS连接到其他正常的实例，在“管理”－“SQL Server日志”中远程查看目标实例的日志记录。
日志中常见几类更新后启动失败的提示,比如错误: 拒绝访问出现在启动过程中，多半是更新操作重置了数据目录的权限，SQL Server服务账户没有足够权限访问数据文件，解决方法是重新给服务账户赋予数据目录的完全控制权限，目录包括数据文件存放目录和备份目录。
再如日志中出现恢复操作无法完成，说明数据库在重启后执行崩溃恢复时遇到问题，这种情况如果日志文件和数据文件没有损坏，重启实例多次通常会完成恢复，不必着急介入，恢复仍然失败时，检查磁盘空间是否足够，系统更新可能消耗大量磁盘空间，数据盘剩余空间不足会导致SQL在启动阶段自动终止。
Windows事件查看器里也有对应的线索,打开“事件查看器”－“Windows日志”－“应用程序”，找时间点最近的来源为MSSQLSERVER的错误事件，比日志更早记录系统层面的异常，比如内存分配失败或服务启动超时，这些信息对于判断具体故障原因已经很充分，业内专家指出，日志中出现的权限或路径类报错，绝大多数属于更新后的配置变动，很少需要重装实例。
关于sql更新后无法连接问题的几个常见问答
Q：SQL更新后本机可以连，局域网其他电脑连不上，是什么原因？
A：优先怀疑防火墙规则和端口状态，本机能连说明服务可用，远程失败代表网络链路被阻断，确认SQL Server监听在1433端口，防火墙入站规则放行该端口，如果用的是命名实例，还需要放行1434端口，之后用局域网内另一台电脑执行telnet 服务器IP 1433验证通断，多数情况下问题出在系统更新重置了防火墙规则。
Q：SQL服务一直显示“正在启动”，卡住不动怎么办？
A：卡在启动状态通常有两种原因，一种是数据库崩溃恢复时间较长，等待即可；另一种是服务账户权限异常，导致启动过程无法读取数据文件，查看ERRORLOG文件的最后几十行，如果有“拒绝访问”字样，将服务账户加入数据目录的安全权限列表，再重启服务，磁盘空间不足也会造成启动停滞，检查数据盘剩余空间是否足够支撑恢复操作。
Q：安全组已经放行1433端口，还是远程连接不上，还有哪里要查？
A：确认SQL Server当前实际监听的端口是否就是1433，命名实例默认使用动态端口，每次服务重启端口都可能变化，防火墙放行的固定端口对应不上，打开SQL Server配置管理器，进入TCP/IP属性，把“动态端口”清空，在“TCP端口”填上1433，重启服务让监听端口固定下来，客户端使用主机名,1433这种格式连接可以绕过实例名解析，端口固定后，再安全组、防火墙、监听三处保持一致即可正常连接。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/611017.html
