数据库还原失败,还原数据库错误3241 收藏 0

鸿萌数据恢复服务: 如何修复 SQL Server 数据库错误 829？

天津鸿萌科贸发展有限公司从事数据安全服务二十余年，致力于为各领域客户提供专业的数据恢复、数据备份、网络及终端数据安全等解决方案与服务。

+

同时，鸿萌是众多国际主流数据恢复软件(Stellar、UFS、R-Studio、ReclaiMe Pro 等)的授权代理商，为专业用户提供正版的数据恢复软件。

SQL Server 错误 829 是与 SQL Server 页面相关的错误。当用户尝试自动修复主数据库中的页面，但由于某种原因而失败时，可能会发生 SQL Server 错误 829。只有当数据库的状态已同步且主数据库正在将数据库日志记录发送到辅助/镜像数据库时，才会执行自动页面修复。

完整的错误信息如下：

Msg 829, Level 16, State 1, Line 1:数据库页面初始化期间发生严重错误。该页面将被标记为“正在恢复”，并且直到从备份中恢复后才可用。

从消息中可以看出，这是一个严重错误（级别 16）。Msg 829 是错误 ID，State 1 表示错误发生在 SQL Server 页面初始化期间。Line 1 是发生错误的行。

有多种原因可能导致此错误。一些常见的原因包括：

• 硬件问题。例如，硬盘故障或硬盘上的坏扇区可能导致数据库损坏，从而导致错误。
• 电源故障。突然断电可能会损坏数据库页面。
• 软件问题。冲突、错误或过时的软件程序也可能损坏数据库。
• 病毒攻击。病毒可能会损坏数据库文件。
• 人为错误。错误更新等操作可能会损坏页面。
• 在数据库恢复期间，如果数据库处于镜像过程中或存在大量并发活动。

由于错误 829 的主要原因是数据库不一致或损坏，因此可以使用 DBCC CHECKDB 命令从备份中还原数据库或修复数据库文件。

如果数据库出现任何问题，首先要做的就是从备份中恢复 SQL 数据库。如果有一个近期健康的备份，请按照以下步骤恢复数据库：

• 打开 SQL Server Management Studio (SSMS) 并连接到 SQL Server 实例。
• 在对象资源管理器中，右键单击数据库节点，然后选择恢复数据库选项。

• 选择设备单选按钮并浏览到备份文件的位置
• 选择备份文件，然后按“确定”恢复数据库。

DBCC CHECKDB 命令用于修复损坏的 SQL Server 数据库。如果没有最近的健康备份，则可以使用 DBCC CHECKDB 命令修复损坏的数据库。

在继续修复数据库之前，您需要将数据库设置为单用户模式。右键单击数据库，选择“属性”，然后选择“选项”页面。在“选项”页面中，选择“SINGLE_USER”模式，然后按“确定”。

当数据库处于单用户模式，运行以下 T-SQL 命令。

DBCC CHECKDB (\’stellardb\’，REPAIR_REBUILD)

GO

如果此命令失败，可以尝试使用以下命令修复数据库。

DBCC CHECKDB (\’stellardb\’，REPAIR_ALLOW_DATA_LOSS)

GO

注意：此命令可能会导致数据丢失。

如果没有备份或 DBCC CHECKDB 命令无法修复数据库，则可以使用专业的 SQL 数据库修复软件 Stellar Repair for MS SQL 进行修复。该软件可以轻松修复数据库并恢复其所有对象，有助于修复 829 错误。

天津鸿萌科贸发展有限公司是 Stellar 系列数据恢复软件的授权代理商。

以下是使用该软件的方法：

注意：下列操作之前，需要使数据库脱机。

• 下载软件并安装。
• 单击“浏览”按钮选择要修复的 SQL Server 数据文件。如果不知道文件位置，请按“查找”按钮查找该文件。

• 然后，按下修复按钮。

• 数据库修复完成后，按“保存”图标。可以将修复后的数据库保存到新数据库、现有数据库（实时数据库）或其他格式（如 Excel 或 CSV）中。

以上解决错误 829 的方案针对专业的数据库人员。对于非专业人员，为了保护数据不受二次损坏，请及时联系专业的数据恢复公司。

天津鸿萌科贸发展有限公司提供专业的数据库恢复及修复服务，凭借二十余年的良好行业口碑，为客户高效解决数据安全问题。

7×24小时在线紧急数据救援服务，及时向客户提供专业的应急响应。

易备数据备份软件支持对 SQL Server、Oracle、MySQL、PostgreSQL、MariaDB、泛微 OA 等数据库进行快速备份，备份过程不会对任何服务造成中断。

使用一份授权，可以备份无限量的数据库，不管数据库服务器是否在本机、本地网络、或是远程网络。可以从网络中的任何一个 Windows 系统中执行数据库的备份任务。软件可以将数据库自动备份到任何目标设备：本地磁盘、NAS、磁带，以及自动通过 FTP、FTPS 和 SFTP 进行传送备份文件，或发送到天翼云、华为云、信服云或 Amazon S3 等云服务。使用本软件可以备份及截断事务日志。

• 实时备份, 不需要任何中断或数据库锁定
• 基于日期和时间的备份任务计划
• 可恢复到一个已存在的数据库或创建一个新数据库
• 内置压缩
• AES 256 位加密
• 多账户和多数据库并行备份
• 自定义备份文件名
• 可以为每一个数据库保存多个备份副本
• 备份校验
• 标准格式的备份文件
• 多副本备份，同时支持云端、FTP、磁带、NAS 等多种备份目的地
• 邮件提醒备份结果
• 防勒索备份检测

数据库数据恢复—空间不足导致sqlserver数据库故障的数据恢复

数据库数据恢复环境：

某品牌r520服务器，服务器中有7块SAS硬盘，这7块硬盘组建了一组2盘raid1阵列和一组5盘raid5阵列，raid1阵列存储空间安装操作系统，raid5阵列存储空间存放数据。服务器上部署sql server数据库，数据库存放在C盘。

数据库故障：

工作人员发现服务器的C盘容量即将耗尽，于是将sql server数据库路径指向D盘，在D盘生成了一个.ndf文件。一个多星期后，sql server数据库出现故障，连接失效，无法正常附加查询。

数据库数据恢复过程：

1、将服务器中所有磁盘编号后取出，硬件工程师对所有磁盘进行检测后没有发现有硬盘存在硬件故障。以只读方式将所有磁盘进行扇区级的全盘镜像，镜像完成后将所有磁盘按照编号还原到原服务器中。

2、基于镜像文件分析RAID结构。根据分析获取到的raid信息重组RAID1和RAID5。

3、在数据库发生故障之后多次在原始环境下尝试恢复数据库，导致原始数据库文件被更改覆盖，磁盘空间被多次复写，无法使用多次尝试恢复后的数据库文件进行修复。和用户方沟通后得知数据库发生故障的时候（尝试恢复数据库之前），工作人员备份过一份的原始数据库文件。

4、从重组的RAID5阵列的存储空间中将备份的数据库文件拷贝出来，尝试在数据库中附加，但是附加失败，出现错误提示。错误提示主数据库文件和次级数据库文件不匹配。

错误提示：

北亚企安数据恢复——sqlserver数据库数据恢复

5、查看.ndf文件底层，发现.ndf文件中几乎没有数据。尝试取消.mdf文件和.ndf文件之间的关联，只用.mdf文件进行附加。只用.mdf文件附加也发生错误，但是错误提示发生改变。错误提示日志文件（.ldf）和数据库文件（.mdf）不匹配。

只用.mdf文件进行附加的错误提示：

北亚企安数据恢复——sqlserver数据库数据恢复

6、尝试将数据库进行无数据库附加，附加成功。但是发现数据库系统表损坏，无法正常使用。

将数据库进行无数据库附加的错误提示：

北亚企安数据恢复——sqlserver数据库数据恢复

7、尝试修复数据库的系统表，由于系统表损坏过于严重，无法修复。

8、解析数据库文件中的数据库记录。北亚企安数据恢复工程师编写相应的程序提取数据库文件中的数据库记录。根据数据库备份获取数据库中的表结构，重构表结构并将提取出的数据库记录导入到新的表中。

9、由用户方对提取出的数据库记录进行验证，经过仔细验证确，用户方确认所有数据完整恢复，认可数据恢复结果。本次数据恢复工作完成。

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 \’FilePath\\FileName\’.

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 Server\\MSSQL.1\\MSSQL\\Data\\www71_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指令可以完成两项任务：

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

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

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会直接失败，数据库也无法做任何修复。此时修复数据库的唯一方法是恢复数据库备份。

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com