DBCC CHECKDB（转载）

 

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

 注意

但是，作为数据库备份和恢复的一部分，将对内存优化文件组中的文件完成 CHECKSUM 验证。

如果内存优化表中出现数据完整性问题，必须从上次已知的正确备份中还原。

  • DBCC CHECKALLOC。

  • DBCC CHECKTABLE。

  • DBCC CHECKCATALOG。

  • 验证数据库中每个索引视图的内容。

  • varbinary(max) 数据时，验证表元数据和文件系统目录和文件之间的链接级一致性。

  • 验证数据库中的 Service Broker 数据。

有关这些命令执行的检查的详细信息，请参阅这些命令的说明。

 
 
 
 
 
DBCC CHECKDB 
[
    [ ( database_name | database_id | 0
        [ , NOINDEX 
        | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
    ) ]
    [ WITH 
        {
            [ ALL_ERRORMSGS ]
            [ , EXTENDED_LOGICAL_CHECKS ] 
            [ , NO_INFOMSGS ]
            [ , TABLOCK ]
            [ , ESTIMATEONLY ]
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]
        }
    ]
]
参数
 
database_name | database_id | 0

标识符

规则。
NOINDEX

NOINDEX 不影响系统表，因为总是对系统表索引执行完整性检查。

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

指定的数据库必须处于单用户模式，才能使用以下修复选项之一。

REPAIR_ALLOW_DATA_LOSS

这些修复可能会导致一些数据丢失。

REPAIR_FAST

未执行修复操作。

REPAIR_REBUILD

这包括快速修复（如修复非聚集索引中缺少的行）以及更耗时的修复（如重新生成索引）。

REPAIR_REBUILD 不修复涉及 FILESTREAM 数据的错误。

 重要提示

如果使用 REPAIR_ALLOW_DATA_LOSS 级别，则建议您在运行带有此选项的 DBCC CHECKDB 之前备份数据库。
ALL_ERRORMSGS

tempdb 数据库生成的那些消息除外。

这两种方法中的任一种都可以确保执行该命令一次即可报告所有错误消息。

EXTENDED_LOGICAL_CHECKS

如果兼容性级别为 100 (SQL Server 2008) 或更高，则对索引视图、XML 索引和空间索引（如果存在）执行逻辑一致性检查。

有关详细信息，请参阅本主题后面“备注”部分中的“对索引执行逻辑一致性检查”。

NO_INFOMSGS

禁止显示所有信息性消息。

TABLOCK

TABLOCK 可使 DBCC CHECKDB 在负荷较重的数据库上运行得更快，但 DBCC CHECKDB 运行时会减少数据库上可获得的并发性。

TABLOCK 限制执行的检查；DBCC CHECKCATALOG 未对数据库运行并且 Service Broker 数据未进行验证。

ESTIMATEONLY

不执行实际数据库检查。

PHYSICAL_ONLY

设计该检查是为了以较小的开销检查数据库的物理一致性，但它还可以检测会危及用户数据安全的残缺页、校验和错误以及常见的硬件故障。

出现此现象的原因是：

  • 逻辑检查更加全面。

  • 要检查的某些基础结构更为复杂。

  • 引入了许多新的检查以包含新增功能。

这些运行的执行频率取决于各业务和生产环境特定的因素。

PHYSICAL_ONLY 始终表示 NO_INFOMSGS，不能与任何一个修复选项一同使用。

 注意

指定 PHYSICAL_ONLY 会使 DBCC CHECKDB 跳过对 FILESTREAM 数据的所有检查。
DATA_PURITY

decimal 或近似 numeric 数据类型列。

有关从 SQL Server 的早期版本升级数据库会对 CHECKDB 有何影响的详细信息，请参阅本主题的“备注”部分。

如果指定了 PHYSICAL_ONLY，则不执行列完整性检查。

解决 SQL Server 2005 和更高版本中的 DBCC 错误 2570。

注释
 

禁用索引和约束。

用户定义类型要求。

如果未设置任何选项，或者设置了 PHYSICAL_ONLY 或 ESTIMATEONLY 选项，则命令返回额外的结果集。

在 SP2 及更高版本中，执行 DBCC CHECKDB 不会清除计划高速缓存。

对索引执行逻辑一致性检查

对索引进行的逻辑一致性检查因数据库兼容性级别而异，如下所示：

  • 如果兼容性级别为 100 (SQL Server 2008) 或更高：

    • 但是，在默认情况下，仅对 XML 索引、空间索引和索引视图执行物理一致性检查。

    • 如果还指定了 NOINDEX，则仅执行逻辑检查。

      因此，建议您仅在以下情况下才指定 WITH EXTENDED_LOGICAL_CHECKS：怀疑存在与物理损坏无关的索引问题，或者已关闭页级校验并且怀疑存在列级硬件损坏。

    • 如果索引为筛选索引，DBCC CHECKDB 将执行一致性检查以验证索引项是否满足筛选谓词的要求。

  • 不支持空间索引。

了解数据库的兼容性级别

内部数据库快照

在这种情况下，需要排他数据库锁才能执行分配检查，需要共享表锁才能执行表检查。

如果无法创建内部数据库快照，则对 master 运行 DBCC CHECKDB 时将失败。

这意味着无法获得所需的事务一致性。

检查和修复 FILESTREAM 数据

对在文件系统中存储 BLOB 的数据库使用 DBCC CHECKDB 时，DBCC 将检查文件系统和数据库之间的链接级一致性。

为修复 FILESTREAM 损坏，DBCC 将删除缺少文件系统数据的任何表行。

最佳做法

应当以什么频率执行这些运行任务将取决于各个企业及其生产环境。

并行检查对象

跟踪标志 (Transact-SQL)。

 注意

SQL Server 2014 各个版本支持的功能的“RDBMS 可管理性”部分中的并行一致性检查。

了解 DBCC 错误消息

下表列出并说明了此消息中可包含的状态值。

 

状态

说明

0

这表示元数据中存在的损坏终止了 DBCC 命令。

1

存在一个内部 DBCC 错误。

2

在紧急模式数据库修复过程中出错。

3

这表示元数据中存在的损坏终止了 DBCC 命令。

4

检测到断言或访问违规。

5

出现终止了 DBCC 命令的未知错误。

错误报告

收集的数据将用于改进 SQL Server 功能。

如果数据收集进程失败，DBCC 命令不会失败。

纠正错误

但是，通过使用 REPAIR_ALLOW_DATA_LOSS 选项来更正错误可能需要删除某些页，因此会删除某些数据。

如果 CHECKDB 检测到此类错误，CHECKDB 将返回一个警告、错误号 2570 以及标识受影响的行和手动更正错误的信息。

修复完成后，备份数据库。

在数据库紧急模式下纠正错误

如果将数据库设置为紧急模式，则该数据库将标记为 READ_ONLY 并禁用日志记录，而且只有 sysadmin 固定服务器角色的成员才能访问它。

 注意

不能在紧急模式下在用户事务内部运行 DBCC CHECKDB 命令并在执行之后回滚事务。

数据库处于紧急模式并且以 REPAIR_ALLOW_DATA_LOSS 子句运行 DBCC CHECKDB 时，将执行以下操作：

  • 这样操作将增加从数据库恢复数据的机会。

  • DBCC CHECKDB 将尝试使用常规的基于日志的恢复方法恢复数据库。

  • 重新生成事务日志可能导致事务一致性丢失。

DBCC CHECKCONSTRAINTS 来发现任何业务逻辑缺陷，并立即备份数据库。

如果 DBCC CHECKDB 命令失败，则无法修复数据库。

在复制的数据库中运行具有 REPAIR_ALLOW_DATA_LOSS 的 DBCC CHECKDB

请注意这些数据库中的下列潜在问题：

  • 可能不会复制由 CHECKDB 进程为修复损坏的用户数据而执行的操作：

    • 如果 CHECKDB 进程插入、更新或删除了行，则触发器不会激发；因此，更改将不会复制。

    • 例如，如果数据页由 CHECKDB 进程释放，则日志读取器代理不会将它翻译为 DELETE 语句；因此，更改将不会复制。

  • 由 CHECKDB 进程为修复损坏的复制元数据表而执行的操作需要删除并重新配置复制。

如果必须对用户数据库或分发数据库运行具有 REPAIR_ALLOW_DATA_LOSS 选项的 DBCC CHECKDB 命令：

  1. 静止复制拓扑（复制 Transact-SQL 编程）。

  2. 执行 DBCC CHECKDB。

  3. 禁用发布和分发。

  4. 如果 DBCC CHECKDB 报表包括任何已复制表的修复，则请执行数据验证以确定发布数据库和订阅数据库中的数据之间是否存在差异。

这些值可能有所不同，除非指定 ESTIMATEONLY、PHYSICAL_ONLY 或 NO_INFOMSGS 选项：

DBCC results for 'model'.

Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13.

Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5.

Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3.

Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3.

Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0.

Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0.

Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0.

DBCC results for 'sys.sysrowsetcolumns'.

There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'.

DBCC results for 'sys.sysrowsets'.

There are 97 rows in 1 pages for object 'sys.sysrowsets'.

DBCC results for 'sysallocunits'.

There are 195 rows in 3 pages for object 'sysallocunits'.

There are 0 rows in 0 pages for object "sys.sysasymkeys".

DBCC results for 'sys.syssqlguides'.

There are 0 rows in 0 pages for object "sys.syssqlguides".

DBCC results for 'sys.queue_messages_1977058079'.

There are 0 rows in 0 pages for object "sys.queue_messages_1977058079".

DBCC results for 'sys.queue_messages_2009058193'.

There are 0 rows in 0 pages for object "sys.queue_messages_2009058193".

DBCC results for 'sys.queue_messages_2041058307'.

There are 0 rows in 0 pages for object "sys.queue_messages_2041058307".

CHECKDB found 0 allocation errors and 0 consistency errors in database 'model'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

指定 NO_INFOMSGS 时，DBCC CHECKDB 返回以下结果集（消息）：

The command(s) completed successfully.

指定 PHYSICAL_ONLY 时，DBCC CHECKDB 返回以下结果集：

DBCC results for 'model'.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

指定 ESTIMATEONLY 时，DBCC CHECKDB 返回以下结果集。

Estimated TEMPDB space needed for CHECKALLOC (KB)

-------------------------------------------------

13

 

(1 row(s) affected)

 

Estimated TEMPDB space needed for CHECKTABLES (KB)

--------------------------------------------------

57

 

(1 row(s) affected)

 

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

权限
 

要求拥有 sysadmin 固定服务器角色或 db_owner 固定数据库角色的成员身份。

示例
 

A.检查当前数据库和其他数据库

DBCC CHECKDB。

Transact-SQL
 
-- Check the current database.
DBCC CHECKDB;
GO
-- Check the AdventureWorks2012 database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks2012, NOINDEX);
GO

B.检查当前数据库，取消信息性消息

以下示例检查当前数据库，并取消所有信息性消息。

Transact-SQL
 
DBCC CHECKDB WITH NO_INFOMSGS;
GO

相关文章：

猜你喜欢
相关资源
相似解决方案
热门标签
Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode