干这行十几年，最怕听到的就是半夜电话那头传来一句：“数据库挂了，起不来了。”尤其是那些还在跑SQL Server 2008的老系统，没有AlwaysOn，没有可用性组，连个像样的备份策略都可能欠着。你打开SSMS一看，数据库状态写着“Suspect”或者“Recovery Pending”，心里那个凉啊。别急，这活儿我接过无数回了，今天就专门聊聊SQL2008数据库损坏修复这件事，把完整步骤掰开揉碎了讲给你听，顺带把那些最容易踩的坑都给你标出来。
先说最要紧的一句话：任何修复操作之前，先把坏掉的数据库文件（.mdf和.ldf）原样复制一份出来，放到安全的地方。不是让你做备份，备份是备份，文件拷贝是文件拷贝。这一步相当于你给病人拍片子之前先留个病理切片，万一修坏了，还有回旋的余地。很多人一上来就执行修复命令，结果越修越烂，连原始文件都找不回来了，那才是真正的欲哭无泪。记住，拷贝文件的时候最好用操作系统命令，别开着数据库服务去拷，不然文件可能被占用或者不一致。
接下来你得先判断损坏的程度。打开SSMS，连上实例，看看那个出问题的数据库在“对象资源管理器”里显示什么状态。如果显示“Recovery Pending”，说明SQL Server启动时发现日志有问题，但还没开始恢复；如果显示“Suspect”，说明恢复过程已经失败，数据库被标记为可疑。还有一种情况是“Offline”，那可能是人为设置的或者磁盘问题。这三种情况处理方式略有差别，但大方向是一致的：先把数据库设为紧急模式，再尝试修复。
具体操作是这样的，打开一个“新建查询”窗口，执行以下语句：
ALTER DATABASE [你的数据库名] SET EMERGENCY;
ALTER DATABASE [你的数据库名] SET SINGLEUSER;
设置成紧急模式后，SQL Server会尝试对数据库做一次轻量级的检查和修复。然后你再执行：
DBCC CHECKDB ([你的数据库名], REPAIRALLOWDATALOSS);
注意，这个命令里的“REPAIRALLOWDATALOSS”翻译成人话就是“允许丢数据”。它会把损坏的页标记为不可用，把那些引用了损坏页的数据删掉。所以执行之前，你心里得有个数：这已经不是“修复”了，是在“抢救”。如果业务数据允许丢一部分，那没问题；如果一条记录都不能少，那你就得考虑用第三方工具或者找专业数据恢复公司了。这个命令执行的时间取决于数据库大小和损坏程度，小的几分钟，大的几个小时，期间别去动它，也别关查询窗口。
执行完DBCC CHECKDB，如果命令返回“repair has completed”之类的提示，恭喜你，数据库已经从紧急模式救回来了。这时候你还需要做两件事：一是把数据库改回多用户模式，二是执行一次完整的DBCC CHECKDB（不带修复参数）确认数据库完整性。多用户模式的命令是：
ALTER DATABASE [你的数据库名] SET MULTIUSER;
至于完整性检查，直接跑一遍不带参数的DBCC CHECKDB就行，它会生成一份详细的报告，告诉你还有没有残留问题。如果报告里全是“OK”或者“0 errors”，那说明修复成功。如果有警告或者错误，那你得考虑是不是还有别的页坏了，可能需要再跑一轮修复，或者检查磁盘有没有坏道、内存有没有问题。
但说实话，上面这套流程能成功，前提是数据库文件本身没有物理损坏太严重。如果文件头坏了，或者日志文件彻底废了，那DBCC CHECKDB可能连数据库都打不开。这时候你就得换一招：尝试重建日志文件。操作方法是在紧急模式下，把日志文件删掉或者改名，然后让SQL Server重新生成一个。步骤是这样的：先停掉SQL Server服务，把.ldf文件改个名字备份起来，再启动服务，这时候数据库会显示“Recovery Pending”，然后你执行：
ALTER DATABASE [你的数据库名] REBUILD LOG;
这个命令会基于数据文件重新生成一个日志文件。注意，这招只适用于日志文件损坏但数据文件相对完好的情况。如果数据文件也坏了，那这招也没用。而且重建日志之后，数据库的日志链就断了，意味着你没法做增量备份，只能做完整备份或者差异备份，这点你得跟业务部门说清楚。
还有一种常见情况，就是数据库能正常打开，但某些表或者某些查询报错，比如“表或视图不存在”或者“I/O错误”。这种属于局部损坏，不需要动整个数据库。你可以单独对那张表执行DBCC CHECKTABLE，看看是不是索引坏了。如果是索引问题，直接重建索引就行，不用惊动整个数据库。重建索引的命令很简单：
ALTER INDEX ALL ON [你的表名] REBUILD;
有时候你发现是某个非聚集索引坏了，那重建那一个索引就够了。这里有个小技巧，执行之前先看一下系统视图sys.dmdbindexphysicalstats，确认到底是哪个索引碎片化严重或者损坏，别一股脑全重建，浪费时间。
修复完了，事儿还没完。你得搞清楚为什么坏。数据库损坏的根源，八成是硬件问题——磁盘坏道、内存故障、电源不稳，这些都会导致写入的数据不完整。剩下两成是人为因素，比如突然强制关机、杀毒软件误删文件、或者某个二把刀DBA手抖执行了错误命令。你修好数据库只是治标，把根源找出来才是治本。比如检查一下Windows事件日志里有没有磁盘相关的报错，跑一下chkdsk检查磁盘坏道，看看服务器有没有内存报错记录。如果这些都没问题，那可能得考虑是不是SQL Server本身有bug，打上最新的Service Pack和补丁。
说点掏心窝子的话。SQL Server 2008早就过了生命周期，微软都不给你发安全补丁了。你费劲修好一次两次，第三次第四次呢？修数据库这事儿，就像救火，火灭了是本事，但更重要的防火。备份策略一定要落实，完整备份加差异备份加日志备份，至少每天一次完整备份，日志备份间隔别超过15分钟。备份文件放在不同的物理磁盘上，最好再拷一份到异地。另外，建议你趁早规划升级到新版本，哪怕是2019或者2022，都比守着2008强。但是，如果你手头那台服务器实在动不了，那至少把今天这套修复流程打印出来贴在机房里，下次再出事儿，照着做，至少能保住大部分数据。SQL2008数据库损坏修复这个活儿，说难也难，说简单也简单，核心就是：先备份，再紧急模式，然后DBCC CHECKDB，查根源。记住这个顺序，你就能在半夜的电话里稳住阵脚。
