对于CS模式的软件系统，数据库文件损坏是常有的事。之所以损坏，我见过最多的场景无非是两种：一是磁盘老化，很多系统使用了较长时间，磁盘还是win7上市前一直使用到现在的；二是断电，有用户一下班就将排插断电或关电源总闸，无非是为了方便和省电。

不管是什么系统，只要使用数据库，我们一定要非常迫切需要对数据库进行备份。CS软件系统，用户是不会主动去备份的，因为他们也不了解数据库，对数据安全也不敏感。也许有较负责任的商家，会帮助客户做好定时备份任务。但发生损坏了，也需要人员进行修复。

接下来我们用一个实际案例进行数据库的修复。某用户附加数据库的 mdf 和 ldf 文件，发生报错无法附加，给到我们进行数据库修复。一般遇到这种情况，我们也会怀疑客户是不是直接拷贝 mdf 和 ldf 进行数据库备份的。

我们可以用SSMS进行数据库附加

USE [master]GOCREATE DATABASE [SampleDB] ON( FILENAME = N'E:\Backup\AAA\mssql\DATA\SampleDB_Data.mdf' ),( FILENAME = N'E:\Backup\AAA\mssql\DATA\SampleDB_log.ldf' ) FOR ATTACHGO

消息 1813，级别 16，状态 2，第 3 行 无法打开新数据库 'SampleDB'。CREATE DATABASE 中止。

消息 824，级别 24，状态 2，第 3 行SQL Server 检测到基于一致性的逻辑 I/O 错误 页撕裂(签名应该为: 0xaaaaaaaa，但实际为: 0x5555aaaa)。在文件 'E:\Backup\AAA\mssql\DATA\SampleDB_Data.mdf' 中、偏移量为 0x0000000a37c000 的位置对数据库 ID 5 中的页 (1:20926) 执行 读取 期间，发生了该错误。SQL Server 错误日志或系统事件日志中的其他消息可能提供了更详细信息。这是一个威胁数据库完整性的严重错误条件，必须立即纠正。请执行完整的数据库一致性检查(DBCC CHECKDB)。此错误可以由许多因素导致；有关详细信息，请参阅 SQL Server 联机丛书。

消息 3313，级别 21，状态 2，第 3 行 在重做数据库 'SampleDB' 的日志中记录的操作时，日志记录 ID (9071:366:30) 出错。通常，特定故障以前会在 Windows 事件日志服务中记录为错误。请利用完整备份还原数据库，或者修复该数据库。

在预期内，果然报错。我们要恢复数据库，必须先把数据文件挂到数据库实例中，我们可以另辟蹊径来达到我们的目的。

1. 创建一个同名数据库

2. 将数据库设置离线

3. 替换数据库mdf与ldf

4. 将数据库设置在线

5. 进行数据库修复

当然，也有些第三方工具可以直接读取 mdf 或 ldf 文件进行数据提取修复，这里我们就不考虑了。现在我们先看看 mdf 与 ldf 的文件信息。

USE [master]GO-- 查看数据库信息DBCC checkprimaryfile (N'E:\Backup\AAA\mssql\DATA\SampleDB_data.mdf' , 2)GODBCC checkprimaryfile (N'E:\Backup\AAA\mssql\DATA\SampleDB_data.mdf' , 3)GO

这些信息可以看到数据库名称、数据库版本、逻辑文件名、原物理文件路径等。我们尽量创建与原路径同名的数据库，可以用 Powershell 直接创建一个完整的路径名称

New-Item -Path "D:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA" -ItemType Directory -Force

​

接下来我们根据以上信息，创建一个新的同名数据库。

CREATE DATABASE [SampleDB]ON  PRIMARY ( NAME = N'xxxx00_Data', FILENAME = N'D:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\SampleDB_Data.mdf' , SIZE = 3072KB , FILEGROWTH = 1024KB ) LOG ON ( NAME = N'xxxx00_log', FILENAME = N'D:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\SampleDB_log.ldf' , SIZE = 1024KB , FILEGROWTH = 10%)GO

创建完成后，我们将该数据库离线（脱机）

ALTER DATABASE [SampleDB] SET OFFLINEGO

离线后，数据文件 mdf 和日志文件 ldf 就可以直接删除了，然后用我们有问题的 mdf 和 ldf 进行替换，有时候需要注意 SQL Server 服务账号是否有权限访问该文件。

替换完成后，我们设置数据库在线。

ALTER DATABASE [SampleDB] SET ONLINEGO

此时会提示出现错误如下，数据库也处于“可疑”状态。

消息926，级别14，状态1，第43行无法打开数据库'SampleDB'。恢复操作已将该数据库标记为SUSPECT。有关详细信息，请参阅SQL Server错误日志。

消息5069，级别16，状态1，第43行ALTER DATABASE语句失败。

消息9003，级别20，状态15，第43行传递给数据库'SampleDB'中的日志扫描操作的日志扫描号(1419:83:1)无效。此错误可能指示数据损坏，或者日志文件(.ldf)与数据文件(.mdf)不匹配。如果此错误是在复制期间出现的，请重新创建发布。否则，如果该问题导致启动期间出错，请从备份还原。

消息3414，级别21，状态1，第43行恢复期间出错，导致数据库'SampleDB' (数据库ID 5)无法重新启动。请诊断并纠正这些恢复错误，或者从已知的正确备份中还原。如果无法更正错误，或者为意外错误，请与技术支持人员联系。

接下来我们可以直接用常用的命令来进行数据库修复。

-- 设置紧急模式ALTER DATABASE SampleDB SET EMERGENCY;--再次检查DBDBCC CHECKDB (SampleDB);--设置单用户模式ALTER DATABASE SampleDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE;--允许数据丢失修复数据库DBCC CHECKDB (SampleDB, REPAIR_ALLOW_DATA_LOSS);--设置多用户模式ALTER DATABASE SampleDB SET MULTI_USER;GO

通过 REPAIR_ALLOW_DATA_LOSS 修复数据，相关修复信息如下。其中大部分是系统元数据有问题，还有一些用户表的索引有问题。修复后新的页面关系可能导致一些异常页面数据丢失。

如果企业丢失了数据，哪怕仅仅几行数据，对企业和客户来说都是非常严重的问题。如果发现数据库损坏，应尽快修复，在修复完成前不建议继续使用该数据库。若某个页面损坏，我们还可以通过备份恢复某个页面的数据。如果损坏过多，即使有损修复数据，数据的完整性也没有保障，数据之间的关系可能已经不存在了，损失也相当于进一步在扩大。

因此，企业或用户系统的数据库，一定要做好备份。不仅要完整的全量备份，还需要日志增量备份。相互结合起来，可以保证任意时刻的数据都能被找回。这一定是数据管理者深入骨髓的理念！

阅读原文：原文链接