SQL Server数据库损坏检测及SQL Server数据库修复解决方案

类型：数据库类大小：25.2M语言：中文评分：3.3标签:立即下载在一个理想的世界里，不会有数据库的损坏，就像我们在日常生活中不会包括一些严重的事故一样，一旦发生这样的事情，肯定会对我们的生活产生非常重大的影响，在SQL Server中也是如此。或许你在数据库中已经有几年没有遇到过这样的情况了，而一旦遇到了这样的情况，那么对于这种情况，我们就需要了解数据库损坏的知识，以便于我们提前做好准备，事后处理。本文将讨论数据库损坏的原因、现象、前后处理方法以及简单的修复方法。

为什么数据库损坏了？

在了解数据库损坏之前，我们应该首先了解SQL Server如何将数据保存到数据文件(MDF、NDF等)。).无论是更新还是插入数据，数据都需要先驻留在内存中的缓冲池中，然后通过CheckPoint和Lazy Writer等过程将内存中的数据持久化到磁盘上。在这个过程中，脏页数据从内存写入持久IO子系统。在此期间，根据不同的输入输出子系统，数据可能会通过这些层：

Windows(写数据必须调用WINDOWS API)

Windows底层的中间层(杀毒软件、磁盘加密系统)

网卡、路由器、交换机、光缆、网线等。(如果输入输出子系统没有直接连接)

存储区域网络控制器(如果使用存储区域网络)

磁盘阵列控制器(输入输出子系统已制成磁盘阵列)

永久性存储，如磁盘或固态硬盘

因此，当一个数据页被写入持久存储时，它可能会经过上面列表中的几个项目。在上述过程中，硬件环境会受到很多方面的影响，比如电压是否稳定、电源故障、温度过高或过低、湿度等。至于软件，由于软件是人写的，可能会有bug，导致数据页面传输过程中出现错误。

此外，影响磁盘的因素还包括电压稳定性、灰尘等因素，这些因素也可能造成坏轨或磁盘整体损坏。

上述所有因素都可以归因于输入输出子系统。所以数据损坏大部分是IO子系统造成的，内存芯片也会造成数据页损坏的概率很小，但这部分情况很小，所以本文不讨论。

上述数据损坏的原因都是自然灾害，也有一些人为灾害。例如，当数据文件由编辑器手动编辑，并且数据库中有需要重做和撤消的事务(即没有Clean shut)时，日志文件被删除(这通常会导致数据库查询)。

发现数据库损坏

在了解了数据库损坏的可能原因后，让我们看看SQL Server是如何监控数据库页面损坏的。

在SQL Server的数据库级别，您可以设置页面保护类型。有三个选项：无、校验和、撕裂页面检测，如图1所示：

图1。页面保护的三个选项

关于这三个选项，首先请忽略无，在任何场景下都不要选择这个选项。此选项意味着SQL Server不保护页面。

下一个是撕页检测。在SQL Server中，数据的最小单位是页，每页是8K，但在相应的磁盘上总是有16个512字节的扇区。如果在写入持久存储的过程中，只写入了一页的一半，这就叫做remote _ PAGE _ DETECTION。SQL Server使用每个扇区中512字节的前2位作为元数据，有16个扇区，32位，4字节的元数据(在页头标记为：m_tornBits)。此元数据用于检测是否存在部分写入的remote _ PAGE，但这种类型的页面验证无法检测页面中的写入错误，因此在SQL Server 2005及更高版本中，请尝试选择CheckSum。

在SQL Server 2005及以上版本中，引入了CheckSum，可以理解为CheckSum。当一个数据页被写入持久存储时，将根据该页的值计算一个4字节的校验和并存储在页头中(与页头中的：m_tornBits相同)，该校验和将与同一页中的数据一起存储在数据库中。当数据从IO子系统读入内存时，SQL Server将根据页面中的值重新计算校验和，并将其与存储在页面标题中的校验和进行比较。如果比较失败，SQL Server会认为页面已经损坏。

从CheckSum过程可以看出，CheckSum仅在页面写入SQL Server时计算，因此如果仅更改数据库选项，页面标题中的元数据不会相应更改。

与输入输出相关的三个错误

根据上面提到的CheckSum原理，SQL Server可以检测到页面损坏，此时，具体表现可能是以下三种错误之一：

823错误，也称为硬IO错误，可以理解为SQL Server想要读取页面，但是Windows告诉SQL Server无法读取页面。

824错误，也就是所谓的软IO错误，可以理解为SQL Server已经读取了页面，但是通过计算CheckSum值发现不匹配，所以SQL Server认为页面已经损坏。

825错误，也称为重试错误。

其中，以上823和824错误均为严重错误，错误级别为24，因此会记录在Windows应用程序日志和SQL Server的错误日志中，导致错误的页面会记录在msdb.dbo.suspect_pages中，错误页码也会记录在SQL Server错误日志中，如图2所示。

图2.824 SQL Server错误记录中的错误描述

因此，如果我们有一个完美的备份，我们可以通过备份来恢复页面(同样，对于数据库管理员来说，它是“准备好的”)，清单1显示了一个简单的页面恢复代码。

使用[master]从磁盘还原数据库[corrupt _ db]page=' 1:155 ' n ' c : \ XXX . bak '，文件=1，norecovery，nounload，stats=5代码清单1。一个简单页面恢复代码从备份中恢复文件ID1中的第155页

还记得我们之前说的，读取页面计算校验和的时候出现了错误，可能是页面本身写入持久存储的错误，也可能是读取页面过程中的错误。此时，SQL Server将再次尝试从IO子系统读取页面，最多可能尝试4次。如果校验和在4次尝试中通过，则为825错误，否则为824错误。这里需要注意的是，与823和824错误不同，825错误是一个只有10级的消息。

因此，由于存在固定的错误号，您可以在SQL Server代理中为823和824设置警报。

备份校验和

只有在使用时，才会检查上述页面校验和(CheckSum)的正确性。备份数据库时，您可以指定CheCk选项，使备份读取的页面也计算校验和，从而确保备份的数据库不会损坏。在图3的备份选项中，我们可以注意到这两个项目：

图3。校验和和错误后继续选项

如果启用了CheckSum，则在备份过程中发现页面校验和错误时将终止备份，如果启用了Continue_After_Error选项，则在检测到校验和错误时将继续备份，从而使备份成功。

如果为备份启用了校验和选项，除了检测每页的校验和之外，还将为整个备份计算校验和，并在备份完成后存储在备份头中。

此外，对于备份，我们还可以通过使用CheckSum进行Restore Verifyonly来验证备份，以确保备份数据没有损坏。

数据库名

如前所述，SQL Server有两种查找错误的方法，即读取页面时和备份时(本质上是读取页面)。但是，如果我们想更彻底地检查数据一致性，就应该定期使用CheckDB检查数据一致性，以免在生产期间读取数据时发现错误。

CheckDB命令对整个数据库进行所有一致性检查。当检查对象是主数据库时，检查数据库也会检查资源数据库。

清单2显示了CheckDB的最简单用法。直接在当前数据库上下文中执行CheckDB将检查当前数据库中的所有内容。

DBCC检查数据库代码清单2。CHECKDB最简单的用法

在企业版中，CheckDB命令将使用多线程来检查整个数据库的一致性。在这个过程中，使用了内置的数据库快照，所以不会造成阻塞，但是CheckDB会消耗大量的CPU、内存和IO。因此，检查数据库应该在维护窗口期间或系统空闲时执行。

默认情况下，CheckDB命令将输出所有信息，但通常我们不关心这些信息，而只关心错误信息，因此在实践中，通常会给DBCC参数，而没有显式信息，如清单3所示。

没有信息管理系统的DBCC检查数据库；代码清单3。CheckDB通常与No_InfoMsgs参数配对

实际上，CheckDB是一组命令的总结，CheckDB将依次检查以下内容：

初始检验系统表

分配单位检查(DBCC支票)

完整的检查系统表

对所有表进行一致性逻辑检查(DBCC检查表)

元数据检查(DBCC检查目录)

单边带检查

检查索引视图、XML索引等

首先，当发现系统表损坏时，只能通过备份来恢复(这就是为什么备份除TempDB之外的系统表非常重要)。其次，在大型数据库中，做CheckDB会花费很长时间，维护窗口时间或者系统空闲时间可能不会覆盖这段时间，所以我们可以将CheckDB的任务分散为三个命令：CHECKALLOC、DBCC CHECKTABLE和DBCC CHECKCATALOG。

有关CheckDB的更多详细信息，请参见：http://technet.microsoft.com/en-us/library/ms176064.aspx.

修复数据库损坏

数据库损坏最有效的方法是拥有冗余数据，并使用冗余数据进行恢复。所谓冗余数据包括热备用、冷备用和热备用。

使用镜像或可用性组作为热备盘可以在检测到错误时自动修复页面(镜像要求高于2008年，可用性组是2012年的功能)。镜像当主体服务器遇到824错误时，它将向镜像服务器发送请求，将损坏的页面从镜像复制到主体服务器以解决问题。对于可用性组，如果在主复制副本上找到数据页面，主复制副本将向所有辅助复制副本发送广播，第一个响应的辅助复制副本的页面将修复页面错误。如果错误发生在只读辅助复制副本中，将从主复制副本请求相应的页面来修复错误。值得注意的是，无论哪种高可用性技术，页面错误都不会扩散到冗余数据，因为SQL Server中所有的高可用性技术都是基于日志，而不是数据页面。

其次，使用热备用或冷备用来恢复页面。我已经在清单1中给出了详细的代码，因此我在这里不再赘述。

如果没有适当的备份，并且非聚集索引上存在损坏的数据页，那么您是幸运的，您只需要禁用索引并重建它。

如果基准有完整备份，并且日志链没有中断(包括差异备份可以覆盖丢失日志的部分)，则可以在备份结束后通过恢复数据库来修复。

最后，如果基础工作做得不好，可能需要通过丢失数据来改变数据库的一致性。我们可以使用DBCC检查数据库的修复允许数据丢失命令来修复数据库。使用这种方法可能会也可能不会导致数据丢失，但在大多数情况下，会删除数据以修复一致性。使用REPAIR_ALLOW_DATA_LOSS需要将数据库设置为单用户模式，这意味着停机。

无论如何，在修复数据库时都要考虑是否满足SLA。如果出现问题，发现无论如何都无法达到SLA，只能回顾一下之前的准备工作，祈祷自己不会失业。

摘要

本文介绍了数据库损坏的概念、SQL Server检测损坏的原理、CheckDB的原理和必要性以及简单的修复方法。提前做好数据库损坏的充分准备，以免事后后悔。就像买保险一样，出事后你也不想买保险吧？