你目前正处于脱机状态,正在等待 Internet 重新连接

如何排除数据库一致性错误报告的 DBCC CHECKB

Extended support for SQL Server 2005 ends on April 12, 2016

If you are still running SQL Server 2005 after April 12, 2016, you will no longer receive security updates and technical support. We recommend upgrading to SQL Server 2014 and Azure SQL Database to achieve breakthrough performance, maintain security and compliance, and optimize your data platform infrastructure. Learn more about the options for upgrading from SQL Server 2005 to a supported version here.

重要说明:本文是由 Microsoft 机器翻译软件进行的翻译并可能由 Microsoft 社区通过社区翻译机构(CTF)技术进行后期编辑,或可能是由人工进行的翻译。Microsoft 同时向您提供机器翻译、人工翻译及社区后期编辑的文章,以便对我们知识库中的所有文章以多种语言提供访问。翻译的文章可能存在词汇、句法和/或语法方面的错误。Microsoft 对由于内容的误译或客户对内容的使用所导致的任何不准确、错误或损失不承担责任。

点击这里察看该文章的英文版: 2015748
症状

执行 DBCC CHECKDB (或其他类似的命令,如存在) 时,SQL Server 错误日志中写入类似以下的消息:

2010-03-31 22:07:06.34 spid53 DBCC CHECKDB (mydb) 执行的 MYDOMAIN\theuser 发现 15 错误并修复 0 个错误。运行时间: 0 小时 0 分 0 秒。内部数据库快照有了拆分点 LSN = 00000026:0000089 d: 0001 和第一个 LSN = 00000026:0000089 c: 0001。这是一个信息性消息。不需要任何用户操作。

此消息显示发现多少数据库一致性错误 (如果修复选项时使用的命令) 已修复多少。此消息也会写入到 Windows 应用程序事件日志中作为错误信息的信息级别 EventID = 8957 (即使此消息信息性级别消息报告了错误)。

在邮件中以"内部数据库快照..."开头的信息,才会显示联机状态,它是数据库不是以 SINGLE_USER 模式运行 DBCC CHECKDB。这是因为对于在线的 DBCC CHECKDB 内部数据库快照用于显示一组一致的数据,以检查。

本文将讨论如何解决每个具体的错误报告的 DBCC CHECKDB 但而不是一般的做法,如果报告了错误。除非专门指出,对 CHECKDB 本文中的任何引用同样适用于对应和 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 所报告的错误将都导致数据丢失。必须运行修复来确定对错误的解决方法将导致数据丢失。一种方法,可帮助缩减的修复级别将为每个表是对应用于报告错误的任何表。这将显示修复一个给定表的最小级别。

若要查找数据库一致性错误发生原因的原因,请考虑这些方法:

  • 检查 Windows 系统事件日志中的任何系统级别、 驱动程序或磁盘相关的错误
  • 检查文件系统的chkdsk 命令的完整性。
  • 运行任何由您的硬件制造商提供的计算机和/或磁盘系统的诊断程序。
  • 使用您的硬件供应商或设备制造商,以确保:
    • 硬件设备和配置SQL Server 的 I/O 要求将确认
    • 将更新的设备驱动程序和 I/O 路径中的所有设备的其它支持软件组件
  • 请考虑使用一个实用程序,如SQLIOSim报告一致性错误的数据库所在的驱动器上。SQLIOSim 是一个独立的 SQL Server 引擎测试的磁盘系统的 I/O 完整性的工具。请注意 SQLIOSim 附带有 SQL Server 2008年,并且不会不 reuiqre 单独下载。
  • 检查报告的 SQL Server,如访问冲突的任何其他错误。这些类型的问题可能会导致数据库损坏所以一定要先解决这些错误。
  • 请确保您的数据库使用的是 PAGE_VERIFY 校验和选项。如果校验和错误报告,它们已写入 SQL Server 后发生错误的一致性页到磁盘,以便应彻底检查您的磁盘系统的指标。有关校验和错误的详细信息,请参阅如何在 SQL Server 中的疑难解答信息 824
  • 查看错误日志中的消息 832 错误。这些是页 5 月的指标都是在之前的缓存已损坏写入磁盘。有关详细信息,请参阅如何解决 SQL Server 中的 Msg 832
  • 请尝试还原数据库备份,您知道,它是"清除"(来自 CHECKDB 没有错误),而您知道的事务日志备份跨越时遇到了错误的时间。如果可以"重播"这个问题通过还原一个"干净"的数据库备份和事务日志,然后与 Microsoft 技术支持部门联系以获得帮助。
  • 数据纯度错误可能插入或更新到 SQL Server 表中的无效数据的应用程序有问题。有关故障排除数据纯度错误请参见下列文章:在 SQL server 2005 中的疑难解答 DBCC 错误 2570年
更多信息

有关 DBCC CHECKDB 和信息/选项 (有关如何执行该命令的语法的详细信息,请阅读DBCC CHECKDB 命令上的 SQL Server 联机丛书主题。

如果通过 CHECKDB 发现任何错误,如下所示的其他消息错误日志中报告错误报告的目的:

2010-03-31 22:07:06.34 spid53 使用 dbghelp.dll 版本"4.0.5"
2010-03-31 22:07:06.35 spid53 * * 转储线程-spid = 0,EC = 0x00000000855F5EB0
2010-03-31 22:07:06.35 spid53 *** 堆栈转储发送到 C:\Program 使用 SQL Server\MSSQL10。SQL2008\MSSQL\LOG\SQLDump0012.txt
2010-03-31 22:07:06.35 spid53      * *******************************************************************************
2010-03-31 22:07:06.35 spid53 *
2010-03-31 22:07:06.35 spid53 * 开始堆栈转储:
2010-03-31 22:07:06.35 spid53 * 03/31/10 22:07:06 spid 53
2010-03-31 22:07:06.35 spid53 *
2010-03-31 22:07:06.35 spid53 * DBCC 数据库损坏
2010-03-31 22:07:06.35 spid53 *
2010-03-31 22:07:06.35 spid53 * 输入缓冲区 84 字节-
2010-03-31 22:07:06.35 spid53 * dbcc checkdb(mydb)
2010-03-31 22:07:06.35 spid53 *
2010-03-31 22:07:06.35 spid53      * *******************************************************************************
2010-03-31 22:07:06.35 spid53      * -------------------------------------------------------------------------------
2010-03-31 22:07:06.35 spid53 * 短堆栈转储
2010-03-31 22:07:06.38 spid53 堆栈转储签名是 0x00000000000001E8
2010-03-31 22:07:07.42 spid53 外部转储过程返回代码 0x20002001。
错误的信息已提交到 Watson 错误报告。

用于错误报告的文件包括 SQLDump < nnn >.txt 文件。该文件可以作为历史记录有用,因为它包含来自 CHECKDB 发现以 XML 格式的错误的列表。

若要查找不为数据库 (最后一个已知干净 CHECKDB) 中检测到错误的情况下最后一次运行 DBCC CHECKDB 时,请检查 SQL Server 错误日志,以了解您的数据库或系统数据库的以下类似的消息 (作为 Windows 应用程序事件日志中的 EventID 信息级别消息写入此消息 = 17573):

2010-04-01 10:13:59.80 spid7s CHECKDB 为母版数据库正确完成 2010年-03-31 22:11:11.417 (当地时间) 上的错误。这是信息性消息。不不需要任何用户操作

注意:本篇“快速发布”文章是从 Microsoft 支持组织直接创建的。 文中包含的信息按原样提供,用于响应紧急问题。 由于发布仓促,材料可能包含印刷错误,并且可能随时修订,恕不另行通知。 有关其他注意事项,请参阅使用条款

属性

文章 ID:2015748 - 上次审阅时间:05/07/2014 07:21:00 - 修订版本: 1.0

Microsoft SQL Server 2005 Developer Edition, Microsoft SQL 2005 Server Enterprise, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL 2005 Server Workgroup, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Express with Advanced Services, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2008 R2 Web, Microsoft SQL Server 2008 R2 Workgroup, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Express, Microsoft SQL Server 2012 Standard, Microsoft SQL Server 2012 Web, Microsoft SQL Server 2014 Developer, Microsoft SQL Server 2014 Enterprise, Microsoft SQL Server 2014 Express, Microsoft SQL Server 2014 Standard, Microsoft SQL Server 2014 Web

  • kbmt KB2015748 KbMtzh
反馈