找回SQL Server数据库其实没那么难，几个简单步骤教你快速恢复数据

前段时间,我的一个朋友，他是个小公司的网管，不是专职的数据库管理员，突然在深夜给我打来紧急电话，声音都变了调，他说他们公司那个用来跑日常业务的SQL Server数据库突然连不上了，服务器上提示有个什么文件损坏还是丢失了，整个系统都瘫痪了，老板急得跳脚，他当时的第一反应就是“完了，数据要是没了，工作可能也保不住了”，我安抚他别慌，然后通过远程一步步指导他操作，最后成功把数据恢复了，这件事让我觉得，很多非专业的朋友一遇到数据库问题就头皮发麻，其实只要思路清晰，找回SQL Server数据库真的没那么可怕，我就把我当时指导他的那几个简单步骤分享给大家，希望能帮到万一遇到类似情况的你。

最重要的一步,也是任何时候都要放在第一位的一步，就是立刻停止任何可能破坏数据的操作，根据我朋友的经验和网上很多技术社区像“CSDN”上一些资深版主反复强调的，当数据库出现故障，尤其是文件丢失或损坏时，第一要务是保护现场，什么意思呢？就是立刻停止对那台数据库服务器进行任何的写入操作，比如不要再尝试启动服务，不要再往里导入数据，甚至最好能跟使用这个数据库的业务系统负责人沟通，暂时把相关的应用服务停掉，因为你不确定损坏的程度，任何不当的写入都可能让本来可以恢复的数据变得彻底无法挽回，这就像一张写坏了的磁盘，你越在上面写新东西，老东西越难找回来。

第二步,我们需要冷静下来，搞清楚到底出了什么问题，你不能像个无头苍蝇一样乱试，SQL Server提供了一个很实用的工具叫SQL Server Management Studio，也就是我们常说的SSMS，你试着去连接一下那个出问题的数据库服务器，如果能连上，但是发现那个数据库的状态显示为“可疑”（Suspect）、”脱机”（Offline）或者“紧急模式”（Emergency），那这就是一个非常明确的信号，说明数据库的核心文件（比如主数据文件.mdf或者日志文件.ldf）可能出了问题，如果连SSMS都连不上服务器，那可能是更底层的服务或者实例出了问题，这一步诊断非常关键，它决定了我们下一步该往哪个方向走，我记得“博客园”里有一篇很详细的文章，就列举了各种数据库状态对应的可能故障原因，非常直观。

第三步,根据第二步的判断，我们来尝试最简单的恢复方法——利用SQL Server自己的还原功能，这是最安全、也是成功率相对较高的首选方案，前提是，你们公司有定期备份数据库的好习惯，怎么做呢？打开SSMS，右键点击那个出问题的数据库，不要点它，而是点“数据库”这个总目录，选择“还原数据库”，在弹出来的窗口里，你选择“源设备”，然后找到你之前备份好的那个.bak文件，系统会自动识别出备份文件里的信息，这里有个小技巧，就像知乎上一位数据恢复专家提到的，在还原之前，务必要勾选“覆盖现有数据库”选项，并且在下方的“选项”页面里，看一下还原后的文件路径是否正确，有时候磁盘路径变了也会导致还原失败，如果备份文件是好的，那么点击执行后，通常就能看到一个成功的提示，数据库状态就恢复正常了。

万一就像我朋友遇到的情况一样,备份文件太旧了，或者干脆就没有备份（这其实很常见），那该怎么办呢？这就进入了第四步，尝试修复数据库文件本身，SQL Server自带了一个命令行工具叫sqlcmd，还有一个数据库控制台命令DBCC CHECKDB，这个方法有点技术含量，但步骤不复杂，具体操作是：在SSMS里把那个问题数据库设置为“紧急模式”，这样我们就能以只读方式访问它，打开命令行，用sqlcmd连接上数据库实例，执行一句命令：DBCC CHECKDB ('你的数据库名', REPAIR_ALLOW_DATA_LOSS)，这条命令会让SQL Server自己去检查和修复数据库内部的错误，需要注意的是，就像很多官方文档里警告的那样，REPAIR_ALLOW_DATA_LOSS这个选项是可能会丢数据的，因为它会为了修复结构完整性而删除掉一些损坏严重的数据页，这是在没有备份情况下的无奈之举，但总比整个数据库完全不能用要强。

如果连DBCC命令都修复不了,比如是数据库文件头损坏严重，或者磁盘物理损坏，那可能就需要求助于第五步，也就是使用专业的数据恢复工具了，市面上有一些第三方的SQL数据库恢复软件，它们的能力有时候比SQL Server自带的工具更强大，能够直接从损坏的.mdf和.ldf文件里提取出表结构和数据，我朋友当时就是在尝试了前几种方法效果不理想后，我建议他下载了一个这类工具的试用版，结果试用版就能扫描出大部分数据，他看到数据能预览出来，心里顿时就有底了，最后公司决定花钱买了授权，成功恢复了超过95%的数据，这是需要付费的，但相比于数据的价值，这笔投入往往是值得的，在选择这类工具时，可以多看看像“开源中国”等社区里的用户评价和对比。

我想特别强调一下,所有这些方法，都抵不上一个万全之策——定期备份，这件事说起来是老生常谈，但太多人总是在出事之后才追悔莫及，你一定要建立一个自动化的备份策略，比如每天一次完整备份，每隔几小时一次事务日志备份，并且要把备份文件复制到另一台物理设备上，不能只放在数据库服务器本地，我朋友的公司经历了这次惊魂事件后，立刻完善了备份机制，现在终于可以睡个安稳觉了。

当SQL Server数据库出现问题时，千万别慌，记住这个顺序：先止损，再诊断，然后从最简单的还原备份开始尝试，不行再一步步升级到修复命令和专业工具，只要你沉着冷静，按部就班，找回数据的概率是非常大的，希望这篇文章永远不会被你需要，但万一需要时，它能给你带来一些帮助和信心。