sqlserver启动老出问题？教你怎么快速定位根源别慌

“sqlserver启动老出问题？教你怎么快速定位根源别慌”

（引用来源：主要思路和部分方法参考自微软官方支持文档、SQL Server Central社区常见问题汇总以及DBA（数据库管理员）的实战经验分享）

sqlserver启动不了，那个小红点或者错误提示一出来，估计很多人的心都凉了半截，数据库停了，业务可能也跟着停了，压力山大，但越是这样越不能慌，一慌就容易乱操作，可能把小问题搞成大麻烦，我们的目标是像老中医一样“望闻问切”,一步步找到病根。

第一步：先看“表面症状”——错误日志说了啥

（引用来源：这是微软官方推荐的首要排查步骤）

sqlserver自己有个“病历本”，就是错误日志，它可比弹窗提示详细多了,你得先找到它在哪里。

最简单的方法是，如果你还能连接到sqlserver的实例（哪怕数据库本身没启动，但服务进程可能还在挣扎），可以用sqlserver management studio (ssms) 连上去，在“管理”下面找到“sql server日志”,查看当前的日志。

如果完全连不上，那就得去硬盘上找文件，日志文件通常在你安装sqlserver的目录下，比如类似这样的路径：c:\program files\microsoft sql server\mssql15.mssqlserver（这里的mssql15版本号可能会变）\mssql\log，里面有几个文件，叫errorlog，errorlog.1, errorlog.2等等，数字越大代表越早的日志，用记事本打开最新的那个errorlog（没有后缀数字的）。

看日志别看花眼了，重点找“错误”或者“严重”级别的信息，通常会有时间戳，错误信息可能很长，但关键的就那几句，它可能会告诉你“无法打开用户数据库xxx的mdf文件”，或者“登录失败”，或者“内存不足”，把这个错误信息的核心内容，比如带引号的文件路径、错误代码（像18456这种）记下来,这就是最重要的线索。

第二步：检查“生命体征”——基础服务和环境

（引用来源：DBA日常巡检的常规操作）

如果日志信息看不明白，或者日志本身都打不开,那就要检查更底层的东西了。

1. 服务启动了没？：去windows的“服务”管理工具里（services.msc），找到你的sqlserver服务（名字通常是“sql server (mssqlserver)”或者有你命名的实例名），看看它的状态是不是“正在运行”，如果不是，试试手动启动它，如果启动失败，系统会弹出一个更具体的错误提示，这个提示往往比sqlserver自己的日志更直接，依赖的服务无法启动”或者“路径找不到”。
2. 硬盘空间够不够？：这是个非常常见但又容易被忽略的问题，sqlserver运行需要空间来写日志、放临时文件，检查一下安装sqlserver的那个盘符（尤其是系统盘和存放数据库文件的盘）是不是快满了，如果空间不足，清理一下临时文件或者转移一些不重要的文件,腾出空间。
3. 权限对不对？：sqlserver服务启动的时候，是以某个“账户”的身份运行的，这个账户必须有权限去访问它需要的那些文件（比如mdf、ldf文件）和注册表等，如果你最近修改过这个账户的密码，或者移动过数据库文件，就很可能出现权限问题，在“服务”里，右键点击sqlserver服务，选择“属性”，在“登录”选项卡里看看它用的是哪个账户,确保这个账户有足够的权限。

第三步：常见“病根”快速自查

根据前面两步的线索,我们可以对照一些常见问题：

• 症状：错误日志提示“无法打开数据库文件”。

  

  • 病根可能：文件被误删了；文件路径不对（可能磁盘映射驱动器失效了）；文件被其他程序占用了（比如杀毒软件在扫描）。
  • 怎么办：检查文件是否存在；如果是映射驱动器，改成绝对路径（如e:\data）；暂时关闭杀毒软件试试。

• 症状：错误日志提示“登录失败”或者错误代码18456。

  • 病根可能：这通常是连接问题，不一定是服务启动问题，但如果是服务启动账户本身登录失败，也会导致服务起不来,可能是账户密码过期或被更改了。
  • 怎么办：回到第二步，检查服务启动账户的密码是否正确,账户是否被禁用。

• 症状：服务一闪就停，日志里可能有内存相关错误。

  • 病根可能：服务器物理内存不足；或者sqlserver的内存设置不合理，比如设置了太大的内存,导致系统本身无法运行。
  • 怎么办：如果可能，先给服务器加内存，如果不行，可以尝试在启动参数里加上“-f”模式（最小配置启动），然后连上去调整内存设置，这个操作有点进阶,如果不熟要小心。

• 症状：之前还好好的，安装了个补丁或重启服务器后就不行了。

  • 病根可能：补丁安装失败或冲突；系统更新影响了某些组件。
  • 怎么办：尝试卸载最近安装的windows更新或sqlserver更新，或者使用sqlserver的配置管理器，尝试用“单用户模式”启动,进行修复。

第四步：终极“杀手锏”——重建日志文件（高风险！）

（引用来源：微软知识库文章关于如何应对可疑事务日志损坏的解决方案）

这是一个万不得已才用的方法，操作前务必想尽一切办法备份现有的mdf文件！ 症状：数据库状态显示“可疑”(suspect)，日志文件可能损坏。 方法：先分离数据库（如果允许的话），然后尝试重新附加，但在附加时，在ssms的附加数据库界面上，选中mdf文件后，右边框里ldf日志文件那一行，直接删除掉，然后点击确定附加，sqlserver会认为日志文件丢失，为你创建一个新的干净的日志文件。 警告：这会丢失最后一次完整备份之后的所有数据操作（即未备份的数据），所以叫高风险，只有在确认数据可丢失或有无备份的前提下,为了紧急恢复服务才考虑。

别慌的核心在于有备份，定期检查你的数据库备份是否有效、是否可恢复，这样即使最坏的情况发生，你也有底气说：“没事，我们从头再来”，平时多流汗，战时少流血，这句话在维护数据库上再正确不过了,希望你的sqlserver能尽快恢复健康！