判断SQL启动的应用服务器是否正常，最直接的方法是检查SQL Server服务状态和对应的端口监听情况，服务在运行且端口正常监听，就说明应用服务器能对外提供数据库服务。 但对于不熟悉Windows服务和网络命令的人，这一堆后台进程和端口号确实容易看花眼，别急，我把这套排查逻辑拆开揉碎,用最贴近实际操作的方式讲清楚。
先分清“SQL启动的应用服务器”到底是什么
很多人把“SQL”和“应用服务器”混为一谈，其实SQL Server本身是数据库服务，它不会跑你的业务代码，真正“启动应用服务器”的，是那些连接SQL Server来读写数据的中间件，比如IIS、Tomcat、Java应用服务，或者是独立的exe程序，你看到的“SQL启动的应用服务器”，本质上是“依赖SQL Server数据库的应用服务”，比如一个用C#写的ERP系统，前台是IIS，后台是SQL Server，你问“怎么看它启动没”,就需要同时确认这两层。
行业共识认为，应用服务器启动失败的原因里，数据库连接串配置错误占了一大半，而SQL Server服务本身没启动的反而少见，所以第一步，必须先确认SQL Server这个“底仓”有没有货。
怎么看SQL启动的应用服务器：三步定位法
这里说的“看”，不是用眼睛盯屏幕，而是用系统工具去查，给你一套组合拳,按顺序来。
第一步：查看SQL Server服务状态
打开Windows服务管理器，最快的方式是按Win + R，输入services.msc回车，在服务列表里找名字类似SQL Server (MSSQLSERVER)的项，注意括号里的实例名，默认实例是MSSQLSERVER，命名实例就是你当初设的名字，看“状态”列，如果是“正在运行”,说明数据库引擎已经启动。
更硬核一点的命令是sc query，打开CMD，输入sc query MSSQLSERVER，看到STATE那行显示RUNNING，就是运行中，这个方法适合写脚本批量检测,手动用也不难。
第二步：查看应用服务器所依赖的端口监听
服务状态是“正在运行”，不代表端口对外开放，SQL Server默认监听1433端口，命名实例可能用动态端口，这时候用netstat -ano | findstr 1433，看有没有一条LISTENING记录，如果有，并且PID对应SQL Server进程，那才叫真正“对外服务中”，这一步非常关键，因为有时候服务起来了，但端口被防火墙挡住，或者被其他进程抢占,应用服务器照样连不上。
第三步：查看SQL Server错误日志确认启动过程无异常
日志是SQL Server自己的日记本，打开SQL Server Management Studio，对象资源管理器里右键实例名，选“查看SQL Server日志”，重点看启动时间那一段，有没有Error: 2（文件找不到）、Error: 5（拒绝访问）、Error: 17182（监听失败）这类记录，没报错,才算干净启动。
sql server启动不了怎么办？排查清单
如果服务状态根本起不来，应用服务器自然就歇菜了，业内专家指出，启动失败的原因里，权限问题占相当大比例，其次是端口冲突和配置损坏,按下面这个清单挨个试。
-
检查服务登录账户：右键服务属性，“登录”选项卡，如果用的是
NT ServiceMSSQLSERVER，一般没问题；如果改成了普通用户，且密码过期或没有“Log on as a service”权限，启动时会报“错误1068”，把账户改成Local System或重新授予权限,多数情况能解决。 -
确认端口没有被占：在CMD里运行
netstat -ano | findstr :1433，如果有其他进程监听了这个端口，SQL Server会因为冲突而启动失败，查出来的PID去任务管理器里看进程名，把占用的软件关掉，或者给SQL Server改端口。 -
看配置文件是否损坏：默认实例的配置文件在
C:Program FilesMicrosoft SQL ServerMSSQL15.MSSQLSERVERMSSQLBinnsqlservr.exe，启动时依赖注册表键值，如果之前手动改过排序规则或实例参数，可能导致配置不匹配，这时候通过sqlservr.exe -f最小配置模式启动,然后重新修正参数。 -
检查实例名是否写错：如果你用的是命名实例，服务名不是
MSSQLSERVER，而是SQL Server (SQLEXPRESS)之类。sc query的时候必须用SQLServer这样的注册表键名吗？不，用服务名，直接sc query "SQL Server (SQLEXPRESS)"，注意带引号和空格，很多人卡在这一步，服务明明在,但查错名字了。
sql server应用服务器连接失败？查这三处
应用服务器启动成功，但前端报“数据库连接失败”，这是另一个高频场景，这里说的“SQL Server应用服务器连接失败”，通常指应用本身连不上SQL Server，而不是SQL Server没启动,按下面三处定位。
看连接字符串里的服务器地址和实例名
打开应用的配置文件，比如web.config或appsettings.json，找到连接字符串。Server=后面写的是什么？如果是localhost，但应用服务器和数据库不在同一台机器，必然失败，如果是0.0.1, 1433，而SQL Server用的动态端口，也会失败，正确写法是Server=数据库IP,端口号;Database=库名;Uid=账号;Pwd=密码,这里最容易踩坑的是把数据库IP写成了应用服务器自己的IP。
看防火墙和网络策略
在数据库服务器上，打开“Windows防火墙高级设置”，确认入站规则里允许TCP 1433端口，如果云服务器，还要看安全组是否放行，很多新手只改系统防火墙，忘记云控制台里还有一道安全组，结果应用服务器死活连不上，可以用telnet 数据库IP 1433测试端口是否通，如果提示连接失败,排除网络层问题。
看SQL Server是否允许远程连接
在SSMS里右键实例，选“属性”->“连接”，勾选“允许远程连接到此服务器”，另外还需要确认SQL Server Browser服务有没有启动，命名实例没有这个服务来做端口解析，客户端就找不到动态端口，多数情况下，SQL Server安装后默认允许远程，但有些老版本默认关闭,需要手动打开。
从监控角度确认SQL应用服务器健康
只看一次状态不够，应用服务器应该持续在线，教你一个不用装第三方工具的办法：用Windows任务计划程序，每隔几分钟跑一条批处理，把sc query结果和netstat结果写到日志文件里，一旦发现状态变了，日志会留下证据，另一种方式是写个简单的SQL查询，比如SELECT 1，如果返回正常，说明数据库链路是通的，这一步可以集成到项目里,也可以手动执行。
怎么看sql启动的应用服务器是否被关闭了
如果应用服务器进程还在，但SQL Server服务被停了，应用会不断重试，直到超时，这时候你看Windows事件查看器，系统日志里有MSSQLSERVER服务终止的记录，再看应用日志，会有超时异常，两个日志一对时间,就知道是谁先出问题。
SQL Server服务自动启动怎么设置
为了防止SQL服务因为断电或重启后不自动运行，打开服务管理器，双击SQL Server服务，把启动类型改成“自动”，如果服务器有多个实例，每个实例都要单独设置，还可以在SQL Server配置管理器里，把SQL Server Browser也设为“自动”,这样命名实例每次都能正常解析端口。
判断SQL启动的应用服务器是否正常，核心就一句话：服务状态+端口监听+日志记录，三者对齐才算真的启动了。 把前面三步定位法和排查清单保存下来，再遇到连接失败，不用慌，按顺序走一遍，基本能找到病根，下次有人问你怎么看SQL启动的应用服务器，你可以告诉他：先看服务，再看端口，最后翻日志,比瞎猜强一百倍。
SQL Server应用服务器连接失败时，常见错误有哪些？
常见的错误码包括：Cannot open database（数据库名错误）、Login failed for user（账号或密码错误）、A network-related error occurred（网络不通）、Named Pipes Provider（命名管道协议不支持），其中网络错误占了较大比例，多半和防火墙或者连接串里的IP写错有关，建议先用telnet IP 1433做连通性测试，如果通了,再检查连接串和登录凭据。
怎么看SQL Server当前监听的端口是不是动态的？
打开SQL Server配置管理器，右键“SQL Server服务”下的实例，选择“属性”->“IP地址”，翻到IPAll，看TCP动态端口那一栏，如果有值，说明是动态端口；如果TCP端口有值，就是固定端口，固定端口写在连接串里即可，动态端口则需要保证SQL Server Browser服务在运行,否则客户端没有自动解析端口的机制。
SQL Server 启动后应用服务器还需要额外配置什么？
应用服务器端需要安装SQL Server客户端，或者至少包含System.Data.SqlClient程序集，如果是.NET Core应用，还需要安装Microsoft.Data.SqlClient这个包，应用服务器的DNS解析要正确，如果连接串用的是机器名，就要确保应用服务器能通过DNS找到数据库机器，多数情况下，直接写IP地址比写机器名更稳,省掉DNS解析这一步。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/746050.html
