SQL Server 2008 R2服务无法启动？ERRORLOG分层定位+最小模式修复指南

简介：遇到SQL Server 2008 R2数据库服务无法启动时，一份精炼的PDF排错手册能节省大量排查时间。这份手册面向DBA、运维人员及遇到同类故障的开发者，聚焦三种典型场景：远程过程调用失败（如安装VS2012自动引入LocalDB导致冲突）、VIA协议配置异常、服务登录账户被更改后无法启动。文中结合真实案例，先分析系统日志与SQL Server日志中的错误表现，再给出卸载冲突服务、禁用VIA协议、恢复本地用户账户等可落地的操作思路，同时提醒通过升级SP1/SP2或预先创建系统还原点来防止问题复发。资源包仅含1个PDF文件，共117KB，内容紧凑，适合离线保存与快速查阅。目前已有1630人学习下载，对于正在部署或维护SQL Server 2008 R2环境的读者而言，是一份值得收藏的故障应急参考。

1. SQL Server 2008 R2 数据库服务无法启动：先把问题分层再动手

凌晨两点收到“数据库连不上”的告警，登上服务器一看，SQL Server 2008 R2 服务是停止状态，右键启动，转几圈又弹回“已停止”，事件日志里写着“发生系统错误 1067”或“服务没有及时响应启动请求”。这种场景对 DBA 和运维来说太熟悉了，而最常见的翻车操作就是一上来就重装实例，或者反复点启动按钮赌它能自己缓过来。

SQL Server 2008 R2 数据库服务无法启动，本质上是三个层面的问题被混在了一起：Windows 服务层有没有把进程拉起来、SQL 引擎层在恢复时有没有卡住或崩掉、网络监听层有没有正常对外应答。绝大多数情况下，引擎层是主要嫌疑，而引擎为什么不起来，ERRORLOG 里基本都写了，只是很多人没看。这篇文章就把我自己处理这类故障的路径完整讲一遍：先分层定位，再用最小恢复模式把实例抬起来，最后逐个修掉 model、tempdb、权限、端口这四个高频故障点。

2. 先分清三层故障：服务、实例、监听，再动手

2.1 服务启动失败的三种形态：闪退、卡住、起一半又停

我一般不会直接点“启动”，而是先看服务面板里当前处于什么状态。同样是“无法启动”，三种形态指向的排查方向完全不同。

第一种是点启动后立刻闪退，服务状态从“已停止”变一下又回到“已停止”，Windows 事件日志里通常伴随“发生系统错误 1067，进程意外终止”。这种情况多数是 SQL Server 引擎在初始化早期就失败了，常见原因包括配置文件损坏、系统数据库文件不可访问、服务账号没有目录权限。此时 ERRORLOG 往往只写了很少几行就中断了。

第二种是卡在“正在启动”，长时间不进入“已启动”，最后超时回到“已停止”。Windows 事件日志里一般会记 1053“服务没有及时响应启动或控制请求”。这种往往是引擎进程活着，但数据库的自动恢复过程卡住了，比如磁盘 IO 慢、系统数据库日志需要回滚、某个库文件损坏导致恢复流程一直循环。这个阶段不要频繁重启，重启只会让恢复工作从头再来，给问题加码。

第三种是服务状态显示“已启动”，但客户端就是连不上，登录服务器看端口也没监听。严格说这不算“服务启动失败”，但用户报障时通常就叫“数据库起不来”，所以排查时要一起处理。

这三种形态对应的是不同层级的故障，先确认属于哪一种，才不会在错误的方向上浪费时间。下面的表可以帮你快速归类。

2.2 ERRORLOG 是唯一不用猜的诊断入口

很多人遇到服务起不来，第一反应是打开“事件查看器”，但 Windows 事件日志只能告诉你“服务没起来”这个结果，真正的原因在 SQL Server 自己的错误日志里。2008 R2 的 ERRORLOG 路径固定在实例目录下，默认实例通常在：

C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG

这个文件没有扩展名，每次启动会轮转一次，旧文件变成 ERRORLOG.1、ERRORLOG.2。排查时我一般直接看最后 30 行，启动失败的原因就藏在最后几行里。用 type 命令读即可：

type "C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG" | findstr /N "错误: 9003 5120 1105 3314 17204 TDSSNIClient"

这条命令的作用是从 ERRORLOG 里过滤出几个关键错误码。9003 代表数据库日志无效，通常指向 model 库或 msdb 库的日志损坏；5120 代表文件打开失败，基本是权限或文件被占用；1105 是磁盘空间不足；3314 是日志文件损坏；17204 是文件路径无法访问。把这些关键字一次搜出来，问题范围就缩小了大半。拿到错误码之后再动手，比盯着服务面板反复点启动要靠谱得多。

另外注意，如果 ERRORLOG 里出现“SQL Server 服务无法启动。有关详细信息，请参阅 SQL Server 联机丛书中的主题……”这段套话，说明引擎在启动早期就退出了，真正的错误码一般在它前面几行。别被这段套话带偏，往前翻才是关键。

2.3 别把 SQL Browser 没启动误判成数据库服务没启动

2008 R2 的命名实例默认使用动态端口，客户端通过实例名连接时，要先问 SQL Browser 服务拿端口。如果 SQL Browser 没启动，或者防火墙挡了 UDP 1434，服务明明活着，客户端却报“找不到实例”或者“连接超时”。这类问题经常被当成“SQL Server 服务无法启动”报上来，处理方式却完全不同。

我遇到这种报障，会先问一句：服务器本机用 sqlcmd 能不能连上。本机能连、远程连不上，基本就是监听或解析层的问题，不是引擎层的问题。再配合 SQL Server 配置管理器确认 TCP/IP 是否启用、动态端口是否被占用。这一步判断对了，能省掉后面所有针对引擎层的折腾。真正引擎起不来的时候，本机也连不上，这是最干脆的区分方法。

3. 用最小恢复模式把实例先抬起来：sqlservr.exe -f -T3608 实战

3.1 最小配置和追踪标志各自解决什么问题

定位完问题之后，下一步不是直接修复，而是先想办法让实例以一种“最小可用”的状态跑起来。SQL Server 2008 R2 提供了几个启动参数，专门用来处理服务起不来的场景。

-f 参数表示最小配置模式启动，它会忽略配置表里的大部分配置项。比如有人把最大内存设得过大、开启了自动关闭、或者某些配置导致引擎启动时自检失败，-f 可以绕开这些配置直接拉起引擎。注意 -f 并不跳过数据库的恢复过程，只是跳过配置层面的障碍。

真正能跳过非 master 库恢复的是追踪标志 -T3608。这个标志会让引擎在启动时只恢复 master 数据库，其他数据库包括 model、msdb、用户库都不做自动恢复。这一点在 model 库损坏时非常关键，因为正常情况下 model 库恢复失败，引擎就会终止启动，而加上 -T3608 后引擎可以绕过 model 的恢复流程先把 master 拉起来。

所以要达到“先让实例起来”这个目标，我习惯把三个参数一起用：-f 忽略配置、-T3608 跳过 model 和用户库的自动恢复、-m"SQLCMD" 只允许一个 sqlcmd 客户端连进来，避免其他连接干扰排查。三者组合起来，是 2008 R2 场景下最稳妥的应急启动组合。

3.2 停掉服务，用前台命令把引擎拉起来

最小恢复模式不能从“服务”面板启动，必须先用命令行把 sqlservr.exe 前台跑起来。操作分两步。

第一步，停掉现有服务。如果服务已经是停止状态可以跳过，但为了保险还是停一次，顺便把 SQL Server 代理等依赖服务一起停掉：

net stop MSSQLSERVER /y

/y 参数的作用是连同依赖这个服务的其他服务一起停止，默认实例的服务名是 MSSQLSERVER，注意区分实例名和服务名。如果是命名实例，服务名一般是 MSSQL$实例名，比如 MSSQL$SQLEXPRESS。停掉之后确认进程已退出，再用 where 或直接切到 Binn 目录启动：

cd "C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn" sqlservr.exe -f -T3608 -m"SQLCMD" -c

这里每个参数都有明确用途。-f 是最小配置模式，忽略配置表里的风险项；-T3608 跳过非 master 数据库的自动恢复；-m"SQLCMD" 限制只有程序名为 SQLCMD 的连接才能进入，避免排查期间有应用连接干扰；-c 表示以控制台方式运行，不注册为 Windows 服务进程。启动后这个命令行窗口不能关，关了引擎就停了。

跑起来之后，命令行窗口里会滚动输出启动信息。正常的 2008 R2 启动日志会显示 master 数据库恢复完成，然后由于 -T3608 的作用，其他数据库会被标记为跳过，整个进程不会退出。如果启动失败，错误会直接打在屏幕上，比翻 ERRORLOG 更直观。这是我首选的启动方式，因为它把启动过程的黑匣子直接打开了。

3.3 实例起来之后，先用 sqlcmd 验证系统库状态

前台窗口输出稳定后，开第二个命令行窗口，用共享内存协议连进去。因为在最小恢复模式下引擎一般不会监听 TCP 端口，默认实例的本地管道地址是 \.\pipe\MSSQL\sql\query：

sqlcmd -S np:\\.\pipe\MSSQL\sql\query -E -Q "SELECT name, state, state_desc FROM sys.databases;"

-E 表示用 Windows 身份认证连接，-S 后面的管道地址是 2008 R2 默认实例的本地共享内存入口，-Q 直接执行查询后退出。执行成功的话，能看到 master、model、msdb、tempdb 和用户库的清单，model 库因为被 -T3608 跳过，状态一般是 RECOVERY_PENDING 或者根本没有被打开，这符合预期。

看到清单后，不要在这个状态下继续做业务操作，因为 model 库没有正常打开，新建连接依赖 model 的模板，此时即使能查数据，也无法创建临时表。接下来要做的是根据 ERRORLOG 里的错误码，决定走哪条修复路径。修完之后，记得先 Ctrl+C 关掉前台窗口，再执行 net start MSSQLSERVER 恢复正常启动。这一步特别容易忘，我曾经在前台进程没退的情况下直接 net start，结果端口被占，服务又起不来，白白多折腾半小时。

4. 定向修复这四个高频点：model、tempdb、权限、端口

4.1 model 数据库损坏：9003 错误与恢复思路

model 库是 SQL Server 的模板库，每次新建数据库、新建临时表都要基于 model 生成初始结构。如果 model 库文件损坏，引擎在启动阶段恢复 model 失败，整个服务就会中止，ERRORLOG 末尾通常能看到类似“错误: 9003，数据库 'model' 的日志无效”的记录。这种损坏常见于异常断电、磁盘故障，或者有人把 model.mdf 文件手动拷贝覆盖过。

处理这个问题的思路取决于有没有备份。有备份的话，在最小恢复模式下直接恢复即可：

RESTORE DATABASE [model] FROM DISK = N'D:\backup\model.bak' WITH REPLACE;

REPLACE 参数用来覆盖现有损坏的 model 文件。执行成功后，重启服务，model 库恢复到正常状态。这里的关键是必须先以 -f -T3608 方式启动，否则引擎在恢复 model 时就挂了，连执行 restore 的机会都没有。

真正麻烦的是没有备份，而大多数人确实不会单独备份 model。这时候有两条路可走。一条是从同版本、同补丁级别的另一台 SQL Server 2008 R2 实例上拷贝一份 model.mdf 和 modellog.ldf 过来应急，但版本不一致会直接拒绝启动，即使能起来也可能埋下隐患；另一条是用安装盘执行 REBUILDDATABASE，重建整个系统数据库。我一般只在实验环境用拷贝文件的方式，生产环境直接走重建，因为后者虽然动作大，但不会出现版本不匹配的玄学问题。注意 REBUILDDATABASE 会把 msdb 也一起重建成空库，之前的所有作业、备份历史、维护计划都会丢失，动手前必须对用户库先做完整备份，这就是翻车的后悔药。

4.2 tempdb 路径失效：启动到一半又失败

tempdb 是每次启动都会重建的库，但它重建之前要读取 master 里记录的物理路径。如果配置好的路径现在不存在了，比如原来放在 E 盘，后来 E 盘被摘掉，或者目录权限被回收，引擎会在创建 tempdb 的阶段失败，整个服务退回停止状态。ERRORLOG 里常见的是 17204 文件无法打开，或者 5120 拒绝访问，启动流程走到一半就停了。

很多人会以为最小恢复模式能绕过 tempdb，实际上 -f -T3608 模式下 tempdb 依然要创建，因为引擎本身依赖它。所以 tempdb 路径失效时，连最小模式都可能起不来。我处理这个问题的顺序是：先确认磁盘在不在，目录在不在，再确认 SQL Server 服务账号对目录有没有完全控制权限。

如果只是权限问题，直接给服务账号授权，有时候就能恢复启动：

icacls "E:\MSSQLData" /T /Q /grant "NT AUTHORITY\NETWORK SERVICE:(OI)(CI)F"

/T 表示递归处理子目录，/Q 是安静模式不逐个确认，/OI 和 /CI 让权限继承到目录下的文件和子文件夹，F 表示完全控制。2008 R2 默认服务账号通常是 NT AUTHORITY\NETWORK SERVICE，如果服务属性里改成了别的账号，要换成对应的账号名。授权完成后重新启动服务，tempdb 就能在路径下重建。

如果问题是磁盘整体不存在了，那就先把原路径恢复出来，或者把旧盘映射回原来的盘符，否则引擎没有机会启动。等实例起来之后，再用 ALTER DATABASE 把 tempdb 挪到稳定路径，改完重启验证一次。这一步的建议是：tempdb 别放在可能会被回收的挂载盘上，本地系统盘虽然不够快，但比“起不来”强得多。

4.3 服务账号与 NTFS 权限：1067 的经典来源

服务面板点启动，立刻闪退，事件日志记录 1067，ERRORLOG 里只有一个 5120 文件打开失败，这种情况十有八九是文件系统权限问题。SQL Server 引擎进程要用服务账号去读数据目录下的 .mdf 和 .ldf 文件，只要账号对目录没有权限，引擎连 master.mdf 都打不开，启动自然失败。

先确认服务用哪个账号登录。打开 services.msc，找到“SQL Server (MSSQLSERVER)”服务，右键属性，切到“登录”选项卡，就能看到服务账号。常见的有 NT AUTHORITY\NETWORK SERVICE、NT AUTHORITY\SYSTEM，也有人改成域账号。改过数据目录到 D 盘或 E 盘的项目，最容易出这个问题，因为安装时默认目录有权限，迁移后新目录经常没给服务账号授权。

确认账号后，用 icacls 给整个数据目录授权，命令和上一节类似，只是把账号换成实际的服务账号：

icacls "D:\SQLData" /T /Q /grant "DOMAIN\sqlservice:(OI)(CI)F"

执行完之后，重新启动服务，一般就能过了。这里还要提醒一个隐蔽的坑：如果服务账号是域账号，而账号密码在 AD 里被改过，服务管理面板里保存的还是旧密码，启动时同样会失败，事件日志里会记录登录失败而不是权限拒绝。遇到这种情况，去服务属性里重新填一遍新密码即可。长期方案是给 SQL 服务建专用账号，并设置密码永不过期，否则每隔几个月就要半夜爬起来改一次密码，血泪经验。

4.4 端口与监听异常：服务起来了客户端还是连不上

排查到最后，有时会发现引擎其实起来了，服务状态也是“已启动”，但 ERRORLOG 前面有一段 TDSSNIClient initialization failed with error 0x2 的记录。0x2 对应的就是地址被占用，通常是固定端口 1433 被其他进程抢了，或者是 SQL Browser 动态端口分配失败。这时引擎可能还能通过共享内存本机访问，但远程客户端一个都进不来。

确认端口占用最直接的方式是用 netstat 看端口归属：

netstat -ano | findstr ":1433" tasklist | findstr "sqlservr"

netstat 输出里最后一列是 PID，拿这个 PID 去 tasklist 里对一下，如果持有 1433 端口的进程不是 sqlservr.exe，就说明端口被占用。解决方式有两种：要么找到占用进程处理掉，要么把 SQL Server 的端口改掉。改端口要打开 SQL Server 配置管理器，在“SQL Server 网络配置”里选 TCP/IP，进入属性，找到 IPAll，把“动态端口”清空，在“TCP 端口”里填一个新的固定端口，然后重启服务。

这里还要区分动态端口和固定端口。2008 R2 命名实例默认用动态端口，每次启动都可能变，客户端靠 SQL Browser 解析。如果 SQL Browser 服务被禁用，即使引擎正常，客户端按实例名连接也会失败。处理方式是启动 SQL Browser，或者把实例改成固定端口，让客户端直接按端口连。这一步做完，客户端连接问题才算真正收尾。

5. SQL Server 2008 R2 服务启动排查避坑：5 条血泪记录

5.1 遇到 1053 就改 ServicesPipeTimeout，治标不治本

现象：服务停在“正在启动”，约 30 秒后回到“已停止”，事件日志记录 1053 服务没有及时响应启动请求。

原因：Windows 服务控制管理器默认给服务 30 秒完成启动，SQL Server 恢复大量数据库时很容易超时。网上常见做法是改注册表里的 ServicesPipeTimeout，把超时拉长。这个操作本身不违法，但很多时候只是把启动窗口拉宽，恢复过程如果真的有文件损坏，改完超时它照样会失败。

解决：先别急着改注册表。打开 ERRORLOG，看启动开始后的恢复阶段，如果卡在某个数据库的“正在恢复”状态，说明这个库有问题，超时只是表象。等恢复完成或者用最小模式绕过该库后，再做针对性修复。改超时只有在确认是磁盘慢、库太多导致正常恢复超时的情况下才用。

5.2 model 损坏后直接把文件删除，指望它自动重建

现象：ERRORLOG 显示 9003 model 库日志无效，有人把 model.mdf 和 modellog.ldf 改名或删除，想着重启后引擎会重新生成一个干净的 model。

原因：SQL Server 2008 R2 不会自动重建 model。model 是引擎启动的必需品，文件缺失时引擎会直接报“无法打开 model 数据库”然后退出，连最小恢复模式都进不去。原本还有机会做 RESTORE 或拷贝文件，删了之后连最后一条路都堵死了。

解决：任何对系统库文件的删除操作都要先冻结。正确做法是先把损坏文件完整复制到别处备份，再用最小模式启动，能进则用 RESTORE 恢复，不能进则用 REBUILDDATABASE 或从同版本实例拷贝文件，最后再考虑删除。

5.3 前台最小模式还没退出，就直接 net start 重启服务

现象：用 sqlservr.exe -f -T3608 前台跑着，修完问题后没关窗口，直接另开一个窗口执行 net start MSSQLSERVER，提示服务已经启动或正在启动，或者刚启动又失败。

原因：同一个实例的 sqlservr.exe 进程已经占用了数据文件，Windows 服务启动时检测到文件被占用，无法正常初始化，最终失败。这类错误在 ERRORLOG 里往往只有一行“无法打开文件”，很容易被误解成权限问题。

解决：先回到前台命令行窗口按 Ctrl+C 让进程正常退出，确认进程消失后再执行 net start。我现在的习惯是准备一个文本文件，把“停服务、前台启动、关前台、启服务”四步命令都写好，避免在凌晨操作时漏掉中间步骤。

5.4 临时调整 tempdb 路径时改了文件没改配置

现象：服务能启动，但每次启动后 tempdb 依然在老路径重建，或者启动直接失败，报 tempdb 文件找不到。有人把 tempdb.mdf 物理移动到了新目录，却漏掉了 ALTER DATABASE 修改逻辑路径。

原因：master 库的 sys.master_files 里记录的是 tempdb 的逻辑路径，引擎启动时严格按这个路径找文件。物理移动文件但没改配置，引擎自然找不到。

解决：物理移动文件之前，先执行 ALTER DATABASE tempdb MODIFY FILE 修改逻辑路径，再复制文件，最后重启验证。两个动作缺一不可，顺序也不能反，只改物理文件不改配置等于白做。

5.5 重建系统库前没备份 msdb，作业全部蒸发

现象：model 损坏被迫 REBUILDDATABASE，完成后服务恢复了，但 SQL Server Agent 里的所有作业、计划、备份历史全部消失，运维体系一夜回到解放前。

原因：REBUILDDATABASE 会重建 master、model、msdb 三个系统库，msdb 被重置成全新空库，里面存储的作业、运算符、备份历史、维护计划一并清空。

解决：执行 REBUILDDATABASE 前必须分别备份 master、model、msdb。如果已经来不及，至少把 msdb 的历史备份找出来，用 RESTORE 恢复回重建后的实例。这个教训告诉我，系统库备份不是可有可无的，尤其维护计划里如果没有覆盖系统库，出一次事就够喝一壶。

6. 把启动失败排查压进 60 秒：一套可复用的定位流程

处理过几次 SQL Server 2008 R2 启动失败之后，我总结出一套固定流程，遇到问题先走一遍，能少走很多弯路。第一步永远是看服务状态和事件日志，确认是闪退还是超时，这决定了后面的方向。

第二步读 ERRORLOG，直接搜错误码。把下面这行命令记在运维手册里，够用一整年：

type "C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG" | findstr /N "9003 5120 1105 3314 17204 TDSSNIClient"

搜出来的错误码直接对应到修复动作：9003 和 3314 是系统库日志损坏，走最小模式加 RESTORE 或重建；5120 和 17204 是权限或路径问题，先检查服务账号和目录是否存在；1105 是磁盘满，清理空间再说；TDSSNIClient 是监听异常，看端口占用和协议配置。这一套对应关系，比翻网页快得多。

第三步是用 -f -T3608 -m"SQLCMD" 把引擎拉起来做现场检查。注意拉起来之后先别动任何文件，先执行查询看 sys.databases 里各库状态，再决定下一步。我有个习惯，每次成功处理完这类故障后，会把当时的 ERRORLOG 复制一份按日期归档，因为同一个实例碰上相似的坑，翻旧日志比查资料更快。

这几年处理下来，最大的教训就是：SQL Server 2008 R2 服务启动失败从来都不是玄学，每一条都写在日志里，关键在于别被 Windows 事件日志的表象带着走，也别在没备份的情况下动系统库文件。希望这套流程能帮你在下次遇到“服务无法启动”时，不必再靠反复点启动按钮碰运气。

本文还有配套的精品资源，点击获取