解决 DBCC CHECKB 报告的数据库一致性错误

本文介绍了如何排查 DBCC CHECKDB 命令报告的错误。

原始产品版本:   SQL Server
原始 KB 编号:   2015748

症状

执行 DBCC CHECKDB (CHECKTABLE) 等其他类似命令时,会向错误日志SQL Server消息:

MyDOMAIN\theuser 执行的日期/时间 spid53 DBCC CHECKDB (mydb) 发现 15 个错误并修复了错误。 已用时间:0 小时 0 分钟 0 秒。 内部数据库快照具有拆分点 LSN = 00000026:00000089d:0001,第一个 LSN = 00000026:00000089c:0001。 此邮件仅供参考。 无需用户操作。

此消息显示找到的数据库一致性错误数,以及修复了 (如果命令一起使用修复选项) 。 此消息还作为 EventID=8957 (信息级别消息写入 Windows 应用程序事件日志,即使报告错误,此消息也是信息级别消息) 。

邮件中以"内部数据库快照..."开始的信息仅在 DBCC CHECKDB 联机运行时显示,其中数据库未在 SINGLE_USER 模式下。 这是因为对于联机 DBCC CHECKDB,内部数据库快照用于显示一组一致的要检查的数据。

本文不讨论如何解决 DBCC CHECKDB 报告的每个特定错误,而是介绍报告错误的一般方法。 本文中对 CHECKDB 的任何引用也适用, DBCC CHECKTABLE CHECKFILEGROUP 除非另有说明。

原因

DBCC CHECKDB 检查数据库页、行、分配页、索引关系、系统表参照完整性和其他结构检查的物理和逻辑一致性。 如果其中任何检查 (选择的选项) ,错误将报告为命令的一部分。

这些问题的原因可能有所不同,例如文件系统损坏、基础硬件系统问题、驱动程序问题、内存损坏的页面或 SQL Server 引擎的问题。 阅读"解决方案"部分,详细了解如何查找报告的错误原因。

解决方案

如果 DBCC CHECKDB 报告一致性错误,则第一个最佳解决方案是从已知良好的备份还原。 但是,如果您无法从备份还原,则 CHECKDB 将提供一种修复错误的功能。 如果文件系统或硬件等系统级别问题可能导致这些问题,建议在还原或运行修复之前先更正这些问题。

运行 DBCC CHECKDB 时,会提供一条建议来指示修复所有错误所需的最小修复选项。 这些消息可能如下所示:

CHECKDB 在数据库"mydb"中发现了 0 个分配错误和 15 个一致性错误。
repair_allow_data_loss 是 DBCC CHECKDB 在 mydb (发现的错误的最低修复) 。

修复建议是尝试解决 CHECKDB 中所有错误的最低修复级别。 这并不意味着此修复选项实际上将修复所有错误。 此外,并非所有报告的错误都可能需要此级别的修复才能解决错误。 这意味着,在建议时,CHECKDB 报告的所有错误 repair_allow_data_loss 都将导致数据丢失。 必须运行修复以确定对错误的解决方法是否会导致数据丢失。 帮助缩小每个表的修复级别的方法之一是,对报告错误的任何表使用 DBCC CHECKTABLE。 这将显示给定表的最低修复级别。

若要找出发生数据库一致性错误的原因,请考虑以下方法:

  • 检查 Windows 系统事件日志中是否有与系统级别、驱动程序或磁盘相关的错误。
  • 使用 chkdsk检查文件系统的完整性。
  • 为计算机和/或磁盘系统运行硬件制造商提供的任何诊断。
  • 与硬件供应商或设备制造商合作,以确保:
    • 硬件设备和配置确认数据库Microsoft SQL Server 输入/输出要求
    • I/O 路径中所有设备的设备驱动程序和其他支持软件组件已更新
  • 请考虑在报告一致性错误的数据库的同一驱动器上使用 类似 SQLIOSim 的实用工具。 SQLIOSim 是独立于 SQL Server 引擎的工具,用于测试磁盘系统 I/O 的完整性。 SQLIOSim 随 SQL Server 2008 一起提供,不需要单独下载。
  • 检查报告的其他错误SQL Server如访问冲突或断言。
  • 确保数据库正在使用 PAGE_VERIFY CHECKSUM 该选项。 如果报告校验和错误,则这些指示在 SQL Server 将页面写入磁盘后发生了一致性错误,因此应彻底检查磁盘系统,请参阅 SQL Server 中的 Msg 824 疑难解答,了解有关校验和错误的详细信息。
  • 在 ERRORLOG 中查找 Msg 832 错误。 这些是指示页面在写入磁盘之前在缓存中时可能损坏的指示器。 有关详细信息 ,请参阅"如何在 SQL Server 中对 Msg 832 进行疑难解答。
  • 尝试还原知道"干净"的数据库备份 (CHECKDB) 和事务日志备份在遇到错误的时间之间没有错误。 如果可以通过还原"干净"数据库备份和事务日志来"重播"此问题,请联系 Microsoft 技术支持寻求帮助。
  • 数据更新错误可能是应用程序在数据表中插入或更新无效数据SQL Server问题。 有关解决 Data Troubleshoot 错误的详细信息,请参阅 SQL server 2005 中的 DBCC 错误 2570 疑难解答

更多信息

有关 DBCC CHECKDB 的语法以及如何执行命令的信息/选项的详细信息,请参阅DBCC CHECKDB (Transact-SQL) 。

如果 CHECKDB 发现任何错误,则 ERRORLOG 中会报告与以下消息类似的其他消息,以便进行错误报告:

日期/时间 spid53 使用"dbghelp.dll"版本"4.0.5"
Date/Time spid53 **Dump thread - spid = 0,EC = 0x000000000855F5EB0
日期/时间 spid53 **_Stack转储发送到FilePath\FileName
Date/Time spid53 _ *********
日期/时间 spid53 *
日期/时间 spid53 * BEGIN STACK DUMP:
Date/Time spid53 * Date/Timespid 53
日期/时间 spid53 *
日期/时间 spid53 * DBCC 数据库损坏
Date/Timespid53 *
日期/时间 spid53 * 输入缓冲区 84 字节 -
Date/Time spid53 * dbcc checkdb (mydb)
日期/时间 spid53 *
日期/时间 spid53 * *********
日期/时间 spid53 * -------------------------------------------------------------------------------
日期/时间 spid53 * 短堆栈转储
转储的日期/时间 spid53 堆栈签名为 0x00000000000001E8
日期/时间 spid53 外部转储进程返回代码 0x20002001。

错误信息已提交给 Watson 错误报告。

用于报告错误的文件包括 SQLDump <nnn> .txt 文件。 此文件可用于历史目的,因为它包含从 CHECKDB 中发现的错误列表,格式为 XML。

若要了解上次在未检测到数据库 (上次已知的干净 CHECKDB) 错误的情况下运行 DBCC CHECKDB 的时间,请检查 SQL Server ERRORLOG,查找数据库或系统数据库 (此消息在 Windows 应用程序事件日志中编写为信息级别消息,EventID = 17573) :

数据库"master"的日期/时间 spid7s CHECKDB 已完成,本地时间为 Date/Time22:11:11.417 (错误) 。 这仅仅是信息性消息;无需用户操作