SQL Server数据库系统破坏检测和SQL Server数据库系统修复解决方案
在一个理想的世界里，任何数据库都不容易被破坏，就像我们不容易把一些严重的紧急情况纳入我们的日常生活一样，一旦发生这样的事情，就会对我们的生活造成非常显著的伤害，在sql server也是如此。也许你在十年内没有遇到过这种情况，一旦遇到这种情况，就会伴随着数据库的丢失、崩溃，甚至你自己的职业生涯也会受到严重影响。所以对于这种情况，首先要了解数据库系统破坏的相关知识，这样才能做好前期准备，以后再处理。因此，在这种情况下，我们应该首先了解数据库系统破坏的相关知识，以便我们可以在早期阶段做好准备，然后进行处理。本文将讨论数据库系统损坏的原因、情况、事先和后续处理方法及其简单的修复方法。
为什么数据库系统会损坏？
在充分了解数据库系统的破坏之前，首先要掌握SQL Server如何将信息存储到数据库文件中？（MDF、NDF等。).无论是升级还是插入数据，数据都必须在内存中提供bufer Pool停留，然后通过CheckPoint和Lazy停留 Writer等链接将内存中的数据持续到硬盘。在此过程中，数据信息脏页由运行内存载入分布式锁的IO分系统。在此期间，根据IO子系统的不同，数据信息很可能通过这些多层次：
Windows(WINDOWS必须用于编写数据信息 API)
Windows底层的内层(计算机杀毒软件，磁盘加密系统软件)
网口、路由器、网络交换机、光钎焊、网线等。(如果IO分系统不直接连接)
SAN控制板(如果使用SAN)
RAID控制板(RAID由IO分系统执行)
持久存储器，如硬盘或SSD
因此，数据页面被写入持久存储期，很有可能通过上述列表中的几类。在上述环节之后，硬件配置也会受到工作电压是否正常、关闭电源、环境温度过高或过低、湿冷等多种危害。在软件方面，由于手机软件都是人写的，可能会出现bug，这可能会导致数据页面在传输过程中出现错误。
此外，危害硬盘的因素还包括工作电压是否正常、灰尘和其他因素，这些因素可能会导致硬盘损坏或整体损坏。
此外，危害硬盘的因素还包括工作电压是否正常、灰尘和其他因素，这些因素可能会导致硬盘损坏或整体损坏。
上述所有元素都可以概括为IO分系统。因此，大多数数据信息损坏都是由IO子系统造成的，闪存芯片的概率相对较小，这也会导致数据页面损坏，但这部分情况几乎为零，因此本文没有讨论。
上述数据信息损坏的原因是自然灾害和一些人为灾害。比如数据库文件是根据在线编辑器手动编写的，数据库中也有Redo和Undo的事务(也就是说，没有Cleann) Shutdown）删除日志文档(通常会引起数据库系统的怀疑)。
发现数据库系统损坏在我们都知道数据库可能会被破坏后，让我们来看看SQL Server是如何检测数据库系统页面损坏的。
在SQL Server数据库等级，可设置页面维护类型，共有三种选择：None，CheckSum，Torn_Page_Detection，如下图1所示：
图1.页面维护的三种选择
关于这三种选择，首先，请忽略None，不要在所有场景中选择这个选项，它代表SQL 保护Server错误页面。
第二TORN__PAGE_DETECTION，在SQL 在Server中，数据库中最小的单位是页面，每页8K，但匹配硬盘上通常有16个512byte的磁道。如果一个页面在载入持久存储的过程中只写了一半，那就叫TORN_。PAGE_DETECTION，SQL Server以每个磁道提512字节数中的前两位为数据库，共有16个磁道32位4字节数的数据库(页面标记为:m_tornBits），通过这个数据库测试是否存在部分TORN_PAGE，然而，这种类型的页面认证无法检测到页面中的输入不正确，因此在SQL中 Server 2005或以上版本号，尽量选择CheckSum。
在SQL Server 2005或以上版本号引入CheckSum，可视为校准位置。当数据页面写入持久存储时，根据页面值计算出一个4字节数的CheckSum隐藏在页面中(页面中的标志相同:m_tornBits），数据库中与信息一起存储在同一页。当数据从IO分系统输入内存时，SQL Server将根据页面中的值再次计算CheckSum，将重算的CheckSum与保存在页面中的CheckSum进行比较。如果检查不成功，SQL Server会觉得页面损坏了。
从CheckSum的一个过程中可以知道，SQL只会写在页面上 CheckSum只能在Server的过程中计算，所以如果只是更改数据库系统的选项，页面上的数据库就不能相应地更改。
三种与IO相关的错误从上述CheckSum的基本原理可以看出，SQL Server可以识别页面损坏。此时，实际表达形式可能与以下三种不正确的形式相一致：
823不正确，也就是我们常说的硬IO不正确，可以看作是SQL Server期待载入页面，Windows告诉SQL Server，无法读取页面。
824不正确，也就是我们常说的软IO不正确，可以看作是SQL Server已经载入了这个页面，但是计算CheckSum的等价是不一致的，所以SQL Server认为这个页面已经损坏了。
824不正确，也就是我们常说的软IO不正确，可以看作是SQL Server已经载入了这个页面，但是计算CheckSum的等价是不一致的，所以SQL Server认为这个页面已经损坏了。
825不正确，即所谓Retry不正确。
在其中， 上述823和824的错误都是不正确等级为24的致命错误，因此可以保存在Windows应用程序日志和SQL中 在Server错误的日志中，导致不正确的页面可以保存在msdb.dbo.suspect_pages中。SQL 如下图2所示，Server错误日志中也会记录出错页的序号。
图2.824SQL不正确 Server错误记录中描述的叙述
因此，如果我们有完整的备份数据，我们可以通过备份数据进行页面恢复（这里特别强调DBA，是的”备”无患)，如代码明细1所示，一个简单的页面恢复编码。
USE [master]RESTORE DATABASE [Corrupt_DB] PAGE='1:155'FROM DISK=N'C:xxx.bak'WITH FILE=1,NOrecovery, NOUNLOAD,STATS=5编码明细1.一个简单的页面恢复编码，文档ID1第155页从备份文件中恢复
记住我们上面说的，在输入页面测量和验证位置时出现错误，这不仅可能是写入持久存储页面本身的错误，也可能是页面输入过程中的错误。此时，SQL Server将尝试从IO分系统中再次载入此页面，更有可能是4次尝试，如果在4次尝试中验位，通常是825不正确，否则是824不正确。这里需要注意的是，与823和824不正确不同的是，825不正确是一个级别，只有10个数据。这里需要注意的是，与823和824不正确不同的是，825不正确是一个级别，只有10个数据。 因此，可以在SQL，因为有固定的不正确序号 Server 在Agent上设置823和824警报器。
备份数据CheckSumm
上述页面CheckSum只有在页面使用时才会被校检页面准确。在备份数据库时，可以指定CheckSum选项，以促进备份数据输入的页面的测量和验证，以确保备份数据库不会损坏。我们可以关注图3中的自动备份选项：
图3.checkSum和Continue_After_Error选择项
如果启动CheckSum，当备份数据发现页面验证错误时，将停止备份数据，启动Continue_After_Error选择项的话，当测试到校验位错误时，备份数据将继续成功。
如果备份数据启动CheckSum选项，除了检查每页的验证位外，整个备份数据将在备份数据结束后计算验证位并存储在备份数据头中。 此外，我们还可以通过Restore进行备份数据 Verifyonly with 检查备份数据的CheckSum，以确保备份数据的信息不受损坏。
DBCC CheckDBSQL是前面提到的 Server发现错误的方法主要有两种，分别是在载入页面和备份数据时(本质上也是载入页面)。但是，如果我们期望对数据一致性进行更激进的检查，我们应该定期使用CheckDB来检测数据的一致性，以免在出厂时间数据被载入时出现未知错误。但是，如果我们期望对数据一致性进行更激进的检查，我们应该定期使用CheckDB来检测数据的一致性，以免在出厂时间数据被载入时出现未知错误。
CheckDB指令将允许所有数据库系统进行所有一致性检查。当检查对象为Master数据库系统时，CheckDB将继续检查ResourceDB。
如编码明细2所示，CheckDB的简单使用方法直接在当前数据库系统的前后文中实施CheckDB，可以检查现阶段数据库中的一切。
DBCC CHECKDB编码明细2.简单使用CheckDB的方法
CheckDB指令将同步应用于公司版本中的线程，这将使所有数据库系统进行一致性检查。在此过程中，采用内置数据库系统快照更新的形式，不会造成堵塞，但CheckDB将消耗大量CPU、内存和IO。因此，CheckDB最好在保护窗口时间或系统软件的业余时间进行。
默认情况下，CheckDB指令会导出所有信息，但我们通常不关心这些数据，只关注错误报告。因此，DBCC特定的非显式信息内容参数值通常在实际操作中显示，如编码明细3。
DBCC CHECKDB WITH NO_INFOMSGS;编码明细3.CheckDB一般组合No_Infomsgs的主要参数
实际上，CheckDB是一组命令的归纳，CheckDB将逐一检查以下具体内容：
第一次检查设备表检查分配模块（DBCC CHECKALLOC）
详细检查设备表对每个表进行一致性逻辑检查（DBCC CHECKTABLE）
元数据检查（DBCC CHECKCATALOG）
SSB查验
检索主视图、XML检索等
最先，如果发现系统表损坏，只能依靠备份数据进行恢复(这就是为什么备份数据除TempDB以外的系统表非常重要)。其次，在大数据库中，CheckDB可以做很长时间，维护窗口时间或系统休闲时间可能不是Cover，所以我们可以将CheckDB任务分散在CheckALOC、DBCC CHECKTABLE、DBCC 在三个指令中，CHECKCATALOG。更多关于CheckDB的信息，客户程序：http://technet.microsoft.com/en-us/library/ms176064.aspx。更多关于CheckDB的信息，客户程序：http://technet.microsoft.com/en-us/library/ms176064.aspx。
修复数据库系统损坏的修复最具破坏性的数据库系统