Microsoft SQL Server数据库管理及开发工具v10.0.7 官方版种类：数据库类大小：25.2M语言：中文 评分：3.3标签：立即下载在一个理想的世界中，不会存在任何数据库的损毁，就像大家不会将一些紧急意料之外状况列入大家日常的平时一样，而一旦这种事情发生，必然会对大家的生活导致很显著的影响，在SQL Server中也同样这样，可能几年内你没遇到过数据库中出现这种状况，而一旦遇到这种状况，总是随着着数据的丢失，宕机，紧急甚至你本身的职业生涯也会遭到影响。因此对于这种状况，大家需要知道数据库损毁方面的常识，以便大家可以事前筹备，事后可以处置。本篇文章会对数据库损毁是什么原因、现象、事前和事后的一些处置办法与简单的修复办法进行探讨。
数据库为何会损毁？
在知道数据库损毁之前，第一大家要知道SQL Server是怎么样将数据保存到数据文件（MDF、NDF等）。无论更新还是插入数据，数据都需要第一在内存中的Buffer Pool驻留，然后通过CheckPoint和Lazy Writer等过程将内存中的数据持久化到磁盘。在这个过程中，数据脏页由内存写入持久化的IO子系统，在此期间，根据IO子系统的不同，数据可能经过这几层：
Windows
Windows底层的中间层（杀毒软件，磁盘加密系统）
网卡、路由器、交换机、光钎、网线等（假如IO子系统不是直连的话）
SAN控制器（假如用了SAN）
R人工智能D控制器（IO子系统做了R人工智能D）
磁盘或SSD等持久化存储器
因此，数据页被写入持久化存储期间，可能经过上述列表中的几项。在历程上述过程中，硬件环境会遭到方方面面的影响，譬如说电压是不是稳定、断电、温度过高或过低、潮湿程度等，而软件方面，因为软件都是人写的，因此就可能存在BUG，这类都可能致使数据页在传输过程中出现错误。
除此之外，影响磁盘的原因也包含电压是不是稳定、灰尘等原因，这类也大概引起磁盘坏道或整体损毁。
上面提到的所有原因都可以被归结为IO子系统。因此，导致数据损毁的状况绝大多数是由IO子系统引起的，还有很很小的概率内存芯片也会致使数据页损毁，但这部分状况微乎其微，因此不在本文的讨论之列。
上面提到的这类致使数据损毁是什么原因都是天灾，还有一些人祸。譬如说通过编辑器等手工编辑数据文件、数据库中还有需要Redo和Undo的事务时（也就是没Clean Shutdown）删除去日志文件（一般会致使数据库质疑）。
发现数据库损毁
在大家了解可能导致数据库的损毁缘由之后，下面大家来看SQL Server是怎么样监测数据库页损毁的。
在SQL Server的数据库级别，可以设置页保护种类，一共有三个选项：None，CheckSum，Torn_Page_Detection，如图1所示：
图1.页保护的三种选项
关于这三种选项，第一，请无视None，请勿在任何场景下选择该选项，该选项意味着SQL Server不对页进行保护。
第二是TORN_PAGE_DETECTION，在SQL Server中，数据的最小单位是页，每一页是8K，但对应磁盘上总是是16个512字节的扇区，假如一个页在写入持久化存储的过程中，只写了一半的页，这就是所谓的TORN_PAGE_DETECTION，SQL Server通过每一个扇区提512字节中前2位作为元数据，总共16个扇区32位4字节的元数据（页头中标识为:m_tornBits），通过该元数据来测试是不是存在部分写的TORN_PAGE，但该种类的页验证没办法测试出页中的写入错误，因此在SQL Server 2005及以上版本，尽可能选择CheckSum。
在SQL Server 2005及以上版本，引入了CheckSum，CheckSum可以理解为校验和，当数据页被写入持久化存储时，会依据页的值计算出一个4字节的CheckSum存于页头（页头中标识同为:m_tornBits），和数据在同一页中一块保存在数据库中。当数据从IO子系统被读取到内存中时，SQL Server会依据页内的值第三计算CheckSum，用该重新计算的CheckSum和页头中存储的CheckSum进行比对，假如比对失败，则SQL Server就会觉得该页被损毁。
由CheckSum的过程可以看出，只有在页被写入SQL Server的过程中才会计算CheckSum，因此假如仅仅改变数据库选项的话，则页头中的该元数据并不会随之改变。
与IO有关的三种错误
通过上述CheckSum的原理可以看出，SQL Server可以测试出页损毁，此时，具体的表现形式可能为下述三种错误的一种：
823错误，也就是所谓的硬IO错误，可以理解为SQL Server期望读取页，而Windows告诉SQL Server，没办法读取到该页。
824错误，也就是所谓的软IO错误，可以理解为SQL Server已经读取到该页，但通过计算CheckSum等值发现不匹配，因此SQL Server觉得该页已经被损毁。
825错误，也就是所谓Retry错误。
其中， 上述823和824错误都是错误等级为24的紧急错误，因此会被记录在Windows应用程序日志和SQL Server的错误日志中，而引起该错误的页会被记录在msdb.dbo.suspect_pages中。SQL Server错误日志中也会记录到出错页的编号，如图2所示。
因此，假如大家存在健全的备份的话，大家可以通过备份进行页还原（在此第三强调一下对于DBA来讲，有”备”无患），一个简单的页还原代码如代码清单1所示。
USE [master]
RESTORE DATABASE [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 Agent中对823和824设置警报。
备份CheckSum
上述页CheckSum只有在页被用时才会被校验页的正确性。在备份数据库时，可以指定CheckSum选项来使得备份读取的页也计算校验和，从而保证了被备份的数据库是没损毁的。在图3的备份选项大家可以注意到这两条：
图3.CheckSum和Continue_After_Error选项
假如启用了CheckSum，当备份过程中发现了页校验和错误时，就会终止备份，而启用了Continue_After_Error选项的话，在测试到校验和错误时，仍然继续从而使得备份成功。
备份假如启用了CheckSum选项，除去测试每一页的校验和以外，还会在备份完成后，对整个备份计算校验和并存储于备份头中。
除此之外，对于备份，大家还可以通过Restore Verifyonly with CheckSum来验证备份，来保证备份的数据没被损毁。
DBCC CheckDB
前面提到SQL Server发现错误的办法有两种，分别为在读取页时和在备份时（本质上也是读取页）。但假如大家期望对于数据一致性的检查愈加的激进，那大家应该按期用CheckDB来检查数据的一致性，而不至于在生产时间数据被读取时才能发现错误。
CheckDB命令会对整个数据库做所有些一致性检查。当检查对象是Master数据库时，CheckDB还会检查ResourceDB。
CheckDB最简单的使用方法如代码清单2所示，在目前数据库上下文中直接实行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的任务分散到CHECKALLOC、DBCC CHECKTABLE、DBCC CHECKCATALOG这三个命令中。
更多关于CheckDB的详细情况，请参阅：http://technet.microsoft.com/en-us/library/ms176064.aspx。
数据库损毁的修复
数据库损毁最行之有效的方法就是存在冗余数据，用冗余数据进行恢复。所谓的冗余数据包含热备、冷备、和暖备。
用镜像或可用性组作为热备，当测试到错误时，可以自动进行页修复（镜像需要2008以上，可用性组是2012的功能）。镜像当主体服务器遭遇824错误时，会向镜像服务器发送请求，将损毁的页由镜像复制到主体解决该问题。对于可用性组，假如数据页是在主副本上发现的，则主副本将会向所有辅助副本发送广播，并由第一个响应的辅助副本的页来修复页错误，假如错误出目前只读辅助副本，则会向主副本请求对应的页来修复错误。在这里有一点值得注意的是，无论是哪一种高可用性技术，都不会将页错误散播到冗余数据中，由于SQL Server中所有些高可用性技术都是基于日志，而不是数据页。
第二是用暖备或冷备来还原页，我已经在代码清单1中给出了详细的代码，这里就不细说了。
假如没适合的备份存在，假如损毁的数据页是存在于非聚集索引上，那样你非常幸运，仅需将索引禁用后重建即可。
假如存在基准的完整备份，并且日志链没断裂（包含差异备份可以Cover日志缺失的部分），则可以通过备份尾端日之后还原数据库来进行修复。
最后，假如基础工作做的并不好，你可能就需要通过损失数据的方法来换回数据库的一致性，大家可以通过DBCC CheckDB命令的REP人工智能R_ALLOW_DATA_LOSS来修复数据库。用该办法可能致使数据损失，也会不会致使数据损失，但大多数状况都会通过删除数据来修复一致性。用REP人工智能R_ALLOW_DATA_LOSS需要将数据库设置为单用户模式，这意味着宕机时间。
无论是哪种状况修复数据库，都要考虑是不是满足SLA，假如出现了问题之后，发现无论用哪种方法都没办法满足SLA的话，那只能反省之前的筹备工作并祈祷你不会因此丢了工作。
小结
本篇文章讲解了数据库损毁的定义、SQL Server测试损毁的原理、CheckDB的原理及必要性和简单的修复方法。对于数据库损毁事前要做好充足的筹备，在事后才不会后悔莫及。就像买保险一样，你可不希望出了事将来再去买保险吧？
TAG标签：SQLServer数据库(1)
转载请说明来源于小浣熊下载站（http://www.tpwno.com）
本文地址：http://www.tpwno.com/news/3641.html
郑重声明：文章来源于网络作为参考，本站仅用于分享不存储任何下载资源,如果网站中图片和文字侵犯了您的版权，请联系我们处理！邮箱3450399331@qq.com
赣公网安备 36010602000087号
相关文章