SQL Server数据库损坏、检测以及简单的修复办法
简介
在一个理想的世界中,不会存在任何数据库的损坏,就像我们不会将一些严重意外情况列入我们生活中的日常一样,而一旦这类事情发生,一定会对我们的生活造成非常显著的影响,在SQL Server中也同样如此,或许几年内您没有遇见过数据库中出现这类情况,而一旦遇见这类情况,往往伴随着数据的丢失,宕机,严重甚至您本身的职业生涯也会受到影响。因此对于这类情况,我们需要了解数据库损坏方面的知识,以便我们能够事前准备,事后能够处理。本篇文章会对数据库损坏的原因、现象、事前和事后的一些处理方法以及简单的修复方法进行探讨。
数据库为什么会损坏?
在了解数据库损坏之前,首先我们要了解SQL Server是如何将数据保存到数据文件(MDF、NDF等)。无论更新还是插入数据,数据都需要首先在内存中的Buffer Pool驻留,然后通过CheckPoint和Lazy Writer等过程将内存中的数据持久化到磁盘。在这个过程中,数据脏页由内存写入持久化的IO子系统,在此期间,按照IO子系统的不同,数据可能经过这几层:
- Windows(写数据一定调用的是WINDOWS API)
- Windows底层的中间层(杀毒软件,磁盘加密系统)
- 网卡、路由器、交换机、光钎、网线等(如果IO子系统不是直连的话)
- SAN控制器(如果使用了SAN)
- RAID控制器(IO子系统做了RAID)
- 磁盘或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所示。
图2.824错误在SQL 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的信息。
因此,由于有固定的错误编号,因此可以在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命令的REPAIR_ALLOW_DATA_LOSS来修复数据库。使用该方法可能导致数据损失,也可能不会导致数据损失,但大部分情况都会通过删除数据来修复一致性。使用REPAIR_ALLOW_DATA_LOSS需要将数据库设置为单用户模式,这意味着宕机时间。
无论是哪种情况修复数据库,都要考虑是否满足SLA,如果出现了问题之后,发现无论用哪种方式都无法满足SLA的话,那只能检讨之前的准备工作并祈祷你不会因此丢了工作。
小结
本篇文章阐述了数据库损坏的概念、SQL Server检测损坏的原理、CheckDB的原理及必要性和简单的修复手段。对于数据库损坏事前要做好充足的准备,在事后才不会后悔莫及。就像买保险一样,你可不会希望出了事以后再去买保险吧?
SQL Server数据库损坏、检测以及简单的修复办法的更多相关文章
- sql server 数据库正在使用该文件的解决办法
今天在帮朋友还原数据库时遇到了一个问题.朋友用的是sql server 2008数据库,本身有一个数据库,他在修改程序的时候,想修改数据库的内容.但是又不想在原数据库中修改.想备份还原出一个数据库然后 ...
- SQL SERVER 数据库被标记为“可疑”的解决办法
问题背景: 日常对Sql Server 2005关系数据库进行操作时,有时对数据库(如:Sharepoint网站配置数据库名Sharepoint_Config)进行些不正常操作如数据库在读写时而无故停 ...
- MS Sql Server 数据库或表修复(DBCC CHECKDB)
MS Sql Server 提供了很多数据库修复的命令,当数据库质疑或是有的无法完成读取时可以尝试这些修复命令. 1. DBCC CHECKDB 重启服务器后,在没有进行任何操作的情况下,在SQL ...
- MS SQL Server数据库修复/MDF数据文件数据恢复/MDF质疑/mdf无法附加
微软的SQL Server 数据库最常用的有两种类型的文件: 1.主要数据文件,文件后缀一般是.MDF: 2.事务日志文件,文件后缀一般是.LDF. 用户数据表.视图.存储过程等等数据,都是存放在MD ...
- SQL Server数据库的三种恢复模式:简单恢复模式、完整恢复模式和大容量日志恢复模式(转载)
SQL Server数据库有三种恢复模式:简单恢复模式.完整恢复模式和大容量日志恢复模式: 1.Simple 简单恢复模式, Simple模式的旧称叫”Checkpoint with truncate ...
- SQL Server数据库有三种恢复模式:简单恢复模式、完整恢复模式和大容量日志恢复模式
SQL Server数据库有三种恢复模式:简单恢复模式.完整恢复模式和大容量日志恢复模式: 1.Simple 简单恢复模式, Simple模式的旧称叫”Checkpoint with truncate ...
- 修改SQL Server数据库表的创建时间最简单最直接有效的方法
说明:这篇文章是几年前我发布在网易博客当中的原创文章,但由于网易博客现在要停止运营了,所以我就把这篇文章搬了过来,因为这种操作方式是通用的,即使是对现在最新的SQL Server数据库里面的操作也是一 ...
- C#对于sql server数据库的简单操作
1.在用windows模式登陆sql server 数据库 简历一个student的数据库,然后新建查询: create table student ( id int auto_increment p ...
- 你所不知道的SQL Server数据库启动过程,以及启动不起来的各种问题的分析及解决技巧
目前SQL Server数据库作为微软一款优秀的RDBMS,其本身启动的时候是很少出问题的,我们在平时用的时候,很少关注起启动过程,或者很少了解其底层运行过程,大部分的过程只关注其内部的表.存储过程. ...
随机推荐
- 如何一步一步用DDD设计一个电商网站(七)—— 实现售价上下文
阅读目录 前言 明确业务细节 建模 实现 结语 一.前言 上一篇我们已经确立的购买上下文和销售上下文的交互方式,传送门在此:http://www.cnblogs.com/Zachary-Fan/p/D ...
- Python高手之路【三】python基础之函数
基本数据类型补充: set 是一个无序且不重复的元素集合 class set(object): """ set() -> new empty set object ...
- 【SSM框架】Spring + Springmvc + Mybatis 基本框架搭建集成教程
本文将讲解SSM框架的基本搭建集成,并有一个简单demo案例 说明:1.本文暂未使用maven集成,jar包需要手动导入. 2.本文为基础教程,大神切勿见笑. 3.如果对您学习有帮助,欢迎各种转载,注 ...
- SQL Server-聚焦NOT IN VS NOT EXISTS VS LEFT JOIN...IS NULL性能分析(十八)
前言 本节我们来综合比较NOT IN VS NOT EXISTS VS LEFT JOIN...IS NULL的性能,简短的内容,深入的理解,Always to review the basics. ...
- .net 分布式架构之业务消息队列
开源QQ群: .net 开源基础服务 238543768 开源地址: http://git.oschina.net/chejiangyi/Dyd.BusinessMQ ## 业务消息队列 ##业务消 ...
- dagger2系列之Scope
Dagger的Scope注解代表的是作用域,通过实现自定义@Scope注解,标记当前生成对象的使用范围,标识一个类型的注射器只实例化一次,在同一个作用域内,只会生成一个实例, 然后在此作用域内共用一个 ...
- [原创]java使用JDBC向MySQL数据库批次插入10W条数据测试效率
使用JDBC连接MySQL数据库进行数据插入的时候,特别是大批量数据连续插入(100000),如何提高效率呢?在JDBC编程接口中Statement 有两个方法特别值得注意:通过使用addBatch( ...
- JQuery的基础和应用
<参考文档> 1.什么是? DOM的作用:提供了一种动态的操作HTML元素的方法. jQuery是一个优秀的js库.用来操作HTML元素的工具. jQuery和DOM ...
- ios 类似微信红点显示功能
设计思路:给UIView增加一个分类 所有的视图都可以根据需要来进行红点显示 #import <UIKit/UIKit.h> @interface UIView (CHRRedDot) @ ...
- linux下 lvm 磁盘扩容
打算给系统装一个oracle,发现磁盘空间不足.在安装系统的时候我选择的是自动分区,系统就会自动以LVM的方式分区.为了保证系统后期的可用性,建议所有新系统安装都采用LVM,之后生产上的设备我也打算这 ...