【SQL Server】DBCC CHECKDB只是一个数据库维护命令吗？

日期：2023年7月27日
作者：Commas
签名：(ง •_•)ง 积跬步以致千里,积小流以成江海……
注释：如果您觉得有所帮助，帮忙点个赞，也可以关注我，我们一起成长；如果有不对的地方，还望各位大佬不吝赐教，谢谢^ - ^
1.01³⁶⁵ = 37.7834；0.99³⁶⁵ = 0.0255
1.02³⁶⁵ = 1377.4083；0.98³⁶⁵ = 0.0006

在这里插入图片描述

文章目录

一、前言
二、DBCC CHECKDB是什么
三、DBCC CHECKDB数据库维护
四、DBCC CHECKDB数据库修复
五、更多常见的 DBCC 命令

一、前言

在了解 DBCC CHECKDB之前，我们先来弄明白 DBCC是什么？

DBCC 是 SQL Server中的一个命令，代表 Database Console Commands，即数据库控制台命令。它提供了一系列用于执行数据库管理任务和诊断操作的命令。

而 DBCC CHECKDB 是其中一个最为常见的命令，该命令用于数据库完整性检查，主要检查数据库的物理和逻辑完整性，查找并报告数据库中的错误和问题。当然，也可以做一些简单的数据库的错误修复工作。

二、DBCC CHECKDB是什么

DBCC CHECKDB 是 Microsoft SQL Server 中用于检查数据库完整性的命令。它是一个数据库维护命令，用于检查数据库的物理和逻辑完整性，以及查找和修复数据库中的错误。

使用 DBCC CHECKDB 可以帮助您发现数据库中可能存在的以下问题：

确保数据库文件的物理完整性，如页面级别的损坏、丢失或交叉链接等。
检查数据库中的索引是否有效，以及索引是否存在损坏或逻辑错误。
检查表之间的引用完整性，以及外键关系是否存在问题。
查找数据库中的逻辑一致性错误，如数据库对象的状态是否正确、分区表的一致性等。
检查数据库的系统表结构是否正确。

三、DBCC CHECKDB数据库维护

要运行 DBCC CHECKDB 数据库维护命令，请使用以下 SQL 语法：

DBCC CHECKDB 
(
    { database_name | database_id | 0}
)
[ WITH 
    {
	    [ ALL_ERRORMSGS ]
	    [ , EXTENDED_LOGICAL_CHECKS ]
	    [ , NO_INFOMSGS ]
	    [ , TABLOCK ]
	    [ , ESTIMATEONLY ]
	    [ , PHYSICAL_ONLY ]
	    [ , DATA_PURITY ]
    }
]

database_name | database_id | 0：指定要检查的数据库的名称、数据库 ID 或 0（表示检查当前数据库）。
ALL_ERRORMSGS：显示所有错误消息（默认为仅显示错误消息）。
EXTENDED_LOGICAL_CHECKS：执行扩展的逻辑检查。这可能需要较长时间。
NO_INFOMSGS：不显示信息消息。
TABLOCK: 在运行 DBCC CHECKDB 时对数据库加锁。这可以防止其他用户访问数据库，但可能会影响数据库的可用性。
ESTIMATEONLY: 只返回估计的检查资源使用情况，而不执行实际检查。
PHYSICAL_ONLY：仅执行物理完整性检查。
DATA_PURITY：检查数据完整性，包括对日期、时间和二进制数据类型的额外检查。
例如，运行以下命令来检查名为 “YourDatabaseName” 的数据库：

DBCC CHECKDB ('<DatabaseName>');

其中，<DatabaseName> 填写我们需要检查的数据库名称。

DBCC CHECKDB 命令可以在维护数据库时定期运行，以确保数据库的完整性，并在发现问题时及时采取修复措施。请注意，运行此命令可能会产生一些系统负载，因此最好在非高峰时段运行。在生产环境中运行之前，最好先在测试环境中进行测试并备份数据库。

四、DBCC CHECKDB数据库修复

要运行 DBCC CHECKDB 数据库修复命令，请使用以下 SQL 语法：

 DBCC CHECKDB 
(
    { database_name | database_id | 0}
	[ , NOINDEX ]  
	[ , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]  
)

第一个参数上面已经介绍过了，这里就不再赘述；

第二个参数 NOINDEX 是一个可选参数，用于指定是否忽略对索引的检查。当指定 NOINDEX 参数时，将只检查表和索引的物理完整性，而不检查索引的逻辑完整性。

-- 检查数据库，并忽略索引检查
DBCC CHECKDB ('<DatabaseName>', NOINDEX);

第三个参数才是重头戏，用于指定在发现数据库问题时的修复行为。值得一提的是，修复可能导致数据丢失，最好先备份后再修复，把损失降到最低。

先备份，再修复
先备份，再修复
先备份，再修复

讲了三遍，表示很重要，划重点要考哦 ^ - ^

REPAIR_ALLOW_DATA_LOSS: 当发现数据库问题时，允许尝试进行修复，即使可能会导致数据丢失。这是最激进的修复选项，应该谨慎使用。
REPAIR_FAST: 尝试使用较少的资源和较少的日志记录来进行修复，但不保证能够解决所有问题。这个选项比较保守，适用于紧急情况下的快速修复。
REPAIR_REBUILD: 尝试使用较多的资源和更多的日志记录来进行修复，以确保尽可能完整地修复数据库中的问题。

-- 检查并尝试使用 REPAIR_ALLOW_DATA_LOSS 修复数据库
DBCC CHECKDB ('<DatabaseName>', REPAIR_ALLOW_DATA_LOSS);

-- 检查并尝试使用 REPAIR_FAST 修复数据库
DBCC CHECKDB ('<DatabaseName>', REPAIR_FAST);

-- 检查并尝试使用 REPAIR_REBUILD 修复数据库
DBCC CHECKDB ('<DatabaseName>', REPAIR_REBUILD);

其中，<DatabaseName> 填写我们需要检查的数据库名称。

修复选项安全指数：REPAIR_REBUILD > REPAIR_FAST > REPAIR_ALLOW_DATA_LOSS

REPAIR_REBUILD 这种修复方式不会导致数据丢失，是一个较安全的选项，但它只能修复一些特定类型的问题，如一些索引或链接错误。对于某些更严重的完整性问题，可能需要使用 REPAIR_ALLOW_DATA_LOSS 或 REPAIR_FAST 选项来解决，但这些选项可能导致数据丢失。

再次强调下，在执行 DBCC CHECKDB 命令时，无论选择哪个修复选项，都建议在生产环境中谨慎操作，并确保在运行命令之前有最近的有效备份。

最后给出后面两种有损修得复选项参数的常见用法，这里以 REPAIR_ALLOW_DATA_LOSS 举例，如下所示：

--（1）将数据库置于紧急模式，只允许管理员有限地访问数据库以诊断关键问题。
ALTER DATABASE <DatabaseName> SET EMERGENCY;

--（2）将数据库设置为一次只允许一个用户连接，通常是将要执行修复操作的数据库管理员。
ALTER DATABASE <DatabaseName> SET SINGLE_USER;

--（3）对数据库进行一致性检查，并尝试修复发现的问题。
DBCC CheckDB (<DatabaseName>, REPAIR_ALLOW_DATA_LOSS); 

--（4）将数据库重新设置为多用户模式，允许正常连接数据库。
ALTER DATABASE <DatabaseName> SET MULTI_USER;