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）删除了日志文件（通常会导致数据库质疑）。

数据库错误检测

如果我们希望对于数据一致性的检查更加的激进，那我们应该定期使用CheckDB来检查数据的一致性，而不至于在生产时间数据被读取时才能发现错误。

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

DBCC CHECKDB -- 检测数据库错误

DBCC CHECKALLOC -- 检测分配单元错误

DBCC CHECKTABLE -- 检索所有表一致性错误

DBCC CHECKCATALOG -- 检测元数据错误

数据库错误修复

use master

declare @databaseName varchar(255)

set @databaseName='数据库名称'

exec sp_dboption @databaseName, N'single', N'true'  -- 将目标数据库置为单用户状态

dbcc checkdb(@databaseName,REPAIR_ALLOW_DATA_LOSS)

dbcc checkdb(@databaseName,REPAIR_REBUILD)

exec sp_dboption @databaseName, N'single', N'false' -- 将目标数据库置为多用户状态

数据表错误修复

use 数据库名称

declare @databaseName varchar(255),@dataTableName

set @databaseName ='数据库名称'

set @dataTableName ='数据表名称'

exec sp_dboption @databaseName ,'single user','true'

dbcc checktable(@dataTableName ,REPAIR_ALLOW_DATA_LOSS)

dbcc checktable(@dataTableName ,REPAIR_REBUILD)

exec sp_dboption @databaseName ,'single user','false'

数据表索引错误修复

DBCC DBREINDEX (表名,’’)