数据库损坏该怎么办 有哪些处理方法以及简单的修复方法

提起数据库损坏（SQL Server数据库损坏、检测以及简单的修复办法） 大家在熟悉不过了，被越来越多的人所熟知，那你知道数据库损坏（SQL Server数据库损坏、检测以及简单的修复办法） 吗？快和小编一起去了解一下吧！

数据库损坏(SQL Server数据库损坏、检测和简单修复)

在一个理想的世界里，不会有任何数据库损坏，就像我们在日常生活中不包括一些严重的突 *** 况一样。这样的事情一旦发生，肯定会对我们的生活产生非常重大的影响，SQL Server也是如此。也许你已经几年没有在一个数据库里看到过这样的情况了，但是一旦遇到这样的情况，往往伴随着数据丢失，宕机，严重的问题甚至你自己的职业生涯都会受到影响。所以对于这种情况，我们需要了解数据库损坏的知识，以便提前做好准备，事后应对。本文将讨论数据库损坏的原因、现象、前后处理方法以及简单的修复方法。

【资料图】

为什么数据库会损坏？

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

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

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

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

SAN控制器(如果使用SAN)

RAID控制器(IO子系统已被RAID)

或者诸如磁盘SSD的永久存储器。

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

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

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

上面提到的数据损坏的原因都是天灾，也有一些是人祸。例如，当数据文件被编辑器等手动编辑，并且数据库中存在需要重做和撤消的事务时(即没有干净关闭)，日志文件被删除(这通常会导致数据库查询)。

发现数据库损坏。

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

在SQL Server的数据库级别，可以用三个选项设置页面保护类型:None、CheckSum、Torn_Page_Detection，如图1所示:

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

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

其次，撕裂_页面_检测。在SQL Server中，数据的最小单位是页，每页8K，但对应的磁盘上往往有16个512字节的扇区。如果在写持久存储的过程中只写了一半的页面，这就叫做TORN_PAGE_DETECTION。SQL Server以每个扇区512字节的前两位作为元数据，总共16个扇区有32位和4字节的元数据(在页头标记为m_tornBits)。通过该元数据，可以检测部分写入的字符串的存在，但是这种类型的页面验证不能检测页面中的写入错误。因此，在SQL Server 2005及以上版本中，应尽可能选择校验和。

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

从校验和的过程可以看出，只有当页面写入SQL Server时，才会计算校验和。因此，如果只更改数据库选项，页眉中的元数据将不会相应地更改。

与IO相关的三个错误

从上面的校验和原理可以看出，SQL Server是可以检测页面损坏的。这时，具体表现可能是以下三种错误之一:

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

824错误，即所谓的软IO错误，可以理解为SQL Server已经读取了页面，但是通过计算校验和的等效值发现没有匹配，所以SQL Server认为页面已经损坏。

85错误，即所谓的重试错误。

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

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

因此，如果我们有一个完美的备份，我们可以通过备份恢复页面(再次强调，对于DBA来说，没有问题)。清单1显示了一个简单的页面恢复代码。

USE[master]RESTOREDATABASE[Corrupt_DB]PAGE="1:155"FROMDISK=N"C:\xxx.bak"WITHFILE=1,NORECOVERY,NOUNLOAD,STATS=5

清单1。一个简单的页面恢复代码，用于从备份中恢复文件ID1中的第155页。

我记得我们之前说过，在读取页面以计算校验和时出现了错误。这可能是写入永久存储器的页面本身的错误，或者是页面读取期间的错误。此时，SQL Server将再次尝试从IO子系统读取页面，最多尝试4次。如果校验和在4次尝试中通过，则为825错误，否则为824错误。请注意，与823和824错误不同，825错误是一条级别仅为10的消息。

因此，因为有固定的错误号，所以可以在SQL Server *** 中为823和824设置警报。

备份校验和

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

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

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

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

此外，对于备份，我们可以通过Restore Verifyonly with CheckSum来验证备份，以确保备份的数据不会损坏。

数据库名

如前所述，SQL Server查找错误有两种方式，即读取页面时和备份时(本质上是读取页面)。但是如果我们想要更积极地检查数据一致性，那么我们应该定期使用CheckDB来检查数据一致性，这样就不会在生产时读取数据时发现错误。

CheckDB命令将对整个数据库进行所有的一致性检查。当检查对象是Master数据库时，CheckDB也会检查ResourceDB。

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

DBCCCHECKDB

清单2。2的最简单用法。数据库名

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

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

DBCCCHECKDBWITHNO_INFOMSGS;

清单3。CheckDB通常带有No_InfoMsgs参数

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

之一次检查系统表

分配单元检查(DBCC检查分配)

检查完整的系统表。

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

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

SSB检查

检查索引、XML索引等。

首先，当发现系统表损坏时，只能通过备份来恢复(这也是为什么备份TempDB以外的系统表非常重要的原因)。其次，在大型数据库中，做一次CheckDB会花费很长时间，维护窗口时间或者系统空闲时间可能都覆盖不了这个时间。然后，我们可以将CheckDB的任务分配给三个命令:CHECKALLOC、DBCC检查表和DBCC检查目录。

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

修复数据库损坏

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

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

第二种是使用热备份或冷备份来恢复页面。我已经在清单1中给出了详细的代码，所以这里不再赘述。

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

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

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

在任何情况下，修复数据库时都应该考虑是否能满足SLA。如果出现问题，发现自己无论如何都达不到SLA，那就只能回顾之前的准备，祈祷自己不要失业。

\