dbnetlib sqlserver不存在或拒绝访问_SQL Server数据库损坏和修复

常见错误解读

823错误

错误信息是：“在文件'%ls'中、偏移量为%#016I64x的位置执行%S_MSG期间，操作系统已经向SQL Server返回了错误%ls。”

“The operating systemreturned error %ls to SQL Server during a %S_MSGat offset %#016I64x in file '%ls'.”

例如：

Msg 823, Level 24, State 3, Line 1

The operating system returned error 5(Access is denied.) to SQLServer during a write at offset 0x0000000000e000 in file 'FilePathFileName'.

823错误代表SQL Server在向操作系统申请某个页面读写时候遇到Windows读取或写入请求失败，Windows返回的错误代码和相应的文本会插入消息中。对于读取操作，SQL Server在报出823错误之前已经重试读取请求4次。

从错误产生的机制可以看出，823错误是发出一个页面读写请求时发生的，和读写的内容没有关系，所以823错误和SQL Server本身无关。通常是物理文件损坏导致此错误，但也可能是设备驱动程序导致的。如果某个数据文件上反复出现823错误，要不就是硬件设备出了问题，要不就是数据文件已经发生了非常严重的损坏。这个错误基本上意味着数据页里的有效数据已经丢失，一般DBCC CHECKDB很难修复。

824错误

错误信息是：”SQL Server检测到基于一致性的逻辑I/O错误%ls。该文件’%ls‘中、偏移量为 %#016I64x的位置对数据库ID%d中的页%S_PGID执行%S_MSG期间，发生了该错误。”

“SQL Server detecteda logical consistency-based I/O error: %ls. It occurred during a %S_MSG of page %S_PGIDin database ID %d at offset %#016I64x in file '%ls'.”

例如：

SQL Server detected a logical consistency-based I/O error: tornpage (expected signature: 0x0; actual signature: 0x4e0372a8). It occurredduring a read of page (1:0) in database ID 13 at offset 0000000000000000 infile 'S:Microsoft SQL ServerMSSQL.1MSSQLDatawww71_global_Data.mdf'.

此错误表明Windows报告已从磁盘成功读取页面，但SQL Server检测到页面中存在逻辑错误。

常见的错误类型有以下几种：

1、CheckSum

SQL Server可以在写入每个页面时，根据页面力度数据算出一个校验值，一同存储到页面里去。当下次读取页面的时候，再根据读到的页面数据，算出一个新的校验值。如果写入和读出的数据一样，那么两个校验值一定是相等的，而如果两个校验值不相等，意味着上次SQL Server写入的数据和这次读出来的内容一定不同，现在读出来的数据有问题。通过这种方法，SQL Server能过发生数据页面损坏。

2、Torn Page

残缺页面(Torn Page)保护其实是一种对电源故障导致的页面损坏进行检测的方法。例如，意外电源故障可能导致一个页面只有一部分被写入了磁盘。在使用残缺页面保护时，页面的每个512字节扇区末尾会放置一个2位签名(在将原来的2位复制到页头之后)。每次进行写操作时，这个签名在二进制数01和10之间交替，这样始终可以确定是否只有部分扇区写到磁盘。如果稍后读取页面时发现某个位置的状态不正确，则说明该页面没有被正确的写入，因此检测到问题页面称为残缺页面。相对于Checksum，残缺页面检测使用的资源最少，但是它的算法太简单，无法检测到磁盘硬件故障导致的所有错误。

3、Short Transfer

读到的数据长度比预期的少。例如，一个读取要求预期可以读到8KB的数据，可是实际只返回了4KB。这也意味着当前读到的页面有损坏。

4、Bad Page Id

在读到页面后，SQL Server会比较页面开头存储的页面编号和自己请求的目标编号。如果发现自己想要读取的页面是第200页，而读到的内容里显示它是第100页，SQL Server会触发824错误。这种错误经常会因为I/O的系统没有正确的处理SQL Server请求，传给SQL Server一个错误的页面，甚至是一个空页面。

5、Restore Pending

在SQL Server的企业版里，用户可以要求在做还原的时候跳过一些损坏的页面(Continue After Error)。这些跳过的页面被标识成“Restore Pending”。如果有的用户想去访问它，就会遇到824错误。

6、Stale Read

一些硬件系统经常发生漏写的现象(SQL Server要求将某个页面写入硬盘文件，I/O子系统报告写入已经完成，可是SQL Server下次读取的时候，读到的还是写入前的内容)。由于读到的老版本页面本身没有什么问题，Checksum和Torn Page算法都不能检查到错误。对这一类问题，SQL Server也有对策。在打开SQL Server启动参数开关-T818以后，SQL Server会在内存里维护一个哈希表，记录所有做过写入动作页面的最新LSN(Log Sequence Number)值。在下次读出页面的时候，会去比较这两个值是否相等。由于LSN是个自动增长的唯一值，每个发生新修改的页面，LSN的值会比原来的要大。如果读到的LSN与内存中存放的不一致，说明上次的写入请求没有真正完成。这时824错误也会触发。

824虽然是一个“逻辑错误”、是SQL Server主动发现的数据损坏，但是损坏的来源大都不是SQL Server自己。这里的错误，主要是由于预期的写入没有完全完成导致的。824错误的原因，基本上还是在I/O子系统。由于SQL Server的读写请求是发给Windows，再由Windows发给底层的磁盘系统，所以问题有可能发生在Windows以下的每一层，例如磁盘驱动器存在故障、磁盘估计存在问题、设备驱动程序不正确等。可以负责任的说，SQL Server自己是不会导致824错误的。

由于824错误是发生在页面这一级的逻辑错误，很多时候DBCC CHECKDB能够修复。这种修复也仅仅是逻辑上的，页面里面存储的数据在824错误发生之前就已经丢失，SQL Server无法将它们修复回来，所以824错误基本也意味着部分数据丢失。

605错误

错误信息是：“尝试在数据库%d中提取逻辑页%S_PGID失败。该逻辑页属于分配单元%I64d，而非%I64d。”

“Attempt to fetchlogical page %S_PGIDin database %d failed. It belongs to allocation unit %I64d not to %I64d.”

例如：

Attempt to fetch logical page (1:584) in database 2 failed. Itbelongs to allocation unit 445237904015360 not to 72057594060079104.

605也是一个非常有名的数据库损坏错误。此错误通常表示指定数据库中的页面或分配已损坏。SQL Server会在根据页链或使用索引分配映射(IAM)读取属于表的页面时，检测到此损坏。分配给表的所有页面必须属于与该表相关联的分配单元之一。如果页眉中包含的分配单元ID不匹配与表相关联的分配单元ID，将引发此异常。错误消息中列出的第一个分配单元ID是页眉中显示的ID，而第二个分配单元值则是与表相关联的ID。

严重级别为21表示可能存在数据损坏。造成的原因包括损坏的页链、损坏的IAM或该对象的sys.objects目录视图中存在无效条目。这些错误通常由硬件或磁盘设备驱动程序故障而引起的。

严重级别为12表示可能存在暂时性错误，即在缓存中出现错误，但不表示对磁盘上的数据造成破坏。暂时性的605错误可由以下条件引发：

操作系统过早的通知SQL Server已完成某个I/O操作；尽管不存在实际的数据损

坏，但现实错误消息。

运行带有优化器提示NOLOCK的查询，或将事务隔离级别设置为READ

UNCOMMITTED。当使用NOLOCK或READ UNCOMMITTED的查询尝试读取

被其他用户移动或更改的数据时，将发生605错误。如果验证是否为暂时性的

605错误，可以稍后重新运行该查询。

通常，如果在数据访问期间发生该错误，但后续的DBCC CHECKDB操作在没有出错的情况下完成，则605错误可能是暂时的。

由于605错误意味着一些页面分配出了问题，所以也是一个非常严重的数据库损坏。一般用DBCC CHECKDB很难修复。

其他错误

在SQL Server内部，除了文件页面分配和每个页面内部格式以外，还有一些其他的约束规则。下面是一些常见的错误例子。

PFS页面投有损坏：

Msg 8946, Level 16, State 12, Line 1Table error: Allocation page(1:13280496) has

invalid PFS_PAGEpage header values.Type is 0. Check type, alloc unit ID and page

ID on the page.

系统表上的聚集索引页面上有损坏：

Server: Msg 8966, Level 16, State 1, Line 1 Could not read andlatch page (1:18645)

with latch type SH. sysindexes failed.

Msg 7985, Level 16, State 2, Server SUNART, Line 1System tablepre-checks: Object

ID 4. Could not read and latch page (1:51) withlatch type SH. Checkstatement

terminated due to unrepairable error.

某个字段的值不符合字段数据类型定义：

Msg 2570, Level 16, State 3, Line 1Page (1:152), slot 0 in objectID 2073058421,

index ID 0, partition ID 72057594038321152, alloc unit ID72057594042318848 (type

"In-row data"). Column "c1" value is out ofrange for data type "datetime". Update

column to a legal value.

元数据有损坏：

Msg 3854, Level 16, State 1, Line 2Attribute (referenced_major_id=2089058478)of

row (class=0,object_id=2105058535,column_id=0,referenced_major_id=2089058478,referenced_

minor_id=0)in sys.sql_dependencies has amatching row (object_id=2089058478)in

sys.objects (type=SN) that is invalid.

遇到这些错误，管理员需要用DBCC CHECKDB命令来检查和修复。有些错误是可以不丢数据就修复的，有些是要丢数据才能修复物理层面错误的，有些是即使丢数据也没办法修复的。

SQL Server数据库损坏修复：DBCC CHECKDB

DBCC CHECKDB指令可以完成两项任务：

检查数据库里有没有损坏发生。
尽力修复数据库损坏，使数据能够重新被正常访问。

所以哪怕是一个正常运行的数据库，也建议定期运行这句指令，以确保没有损坏发生。对于已经发生访问错误的数据库，应该第一时间运行这句指令，了解损坏的范围和程度。

DBCC CHECKDB在做什么

DBCC CHECKDB通过依次执行下列操作检查指定数据库中所有对象的逻辑和物理完整性：

检查一些关键的系统表。
对数据库运行DBCC CHECKALLOC。
对数据库中的每个表和视图运行DBCC CHECKTABLE。
对数据库运行DBCC CHECKCATALOG。
验证数据库中每个索引视图的内容。
验证数据库中的Service Broker数据。

这意味着运行了DBCC CHECKDB，就不必再单独运行DBCC CHECKALLOC、DBCC CHECKTABLE或DBCC CHECKCATALOG命令。也意味着单独运行DBCC CHECKALLOC、DBCC CHECKTABLE和DBCC CHECKCATALOG命令，虽然不能完全完成DBCC CHECKDB的所有功能，但是至少完成了大部分功能。

1、检查一些关键的系统表

在检查数据库之前，SQL Server需要了解这个数据库里到底存放了什么样的数据，也就是所谓数据库的“元数据”(Metadata)。没有这些信息，SQL Server无法知道自己将要去访问什么样的表格，也就没办法知道自己应该怎么解释将要读到的记录。

关键系统表有：

sysallocunits。

syshobts。

syshobtcolumnes。

sysrowsets。

sysrowsetcolumns。

对于普通用户访问，这些表都是不可见的，只有在DAC模式下的连接才能看到它们。它们的结果对普通用户也是透明的。

这里的每一张系统表都有一个聚集索引。SQL Server会像做CHECKTABLE一样，对这些系统表做一遍检查，确保这些表格里的每一页及页面里的每一条数据都可以正确的读出来。如果中间发现问题了，例如，发现某个页面不能被正常访问，SQL Server会报错。例如：

Server: Msg 8966, Level 16, State 1, Line 1

Could not read and latch page (1:33245) with latch type SH.Sysobjects failed.

对于小的数据库，这些存放元数据库的系统表不会占用太多的页面。如果发生硬件问题，损坏的概率比较小。对于一些有成千上万对象的数据库，这些元数据系统表本身可能使用了很多页面，发生损坏的概率也随之增大。由于这些系统表正确读取一切数据的根本，所以如果任意一张系统表上发生了损坏，DBCC CHECKDB会直接失败，数据库也无法做任何修复。此时修复数据库的唯一方法是恢复数据库备份。