目录
（一）前言
（二）关于DBCC CHECKxxx系列命令
1. DBCC CHECKALLOC
2. DBCC CHECKCATALOG
3. DBCC CHECKDB
（1）基本概念
（2）基本语法
（3）参数说明
（三）实际操作案例
1. 将数据库状态改为紧急模式
2. 将数据库改为单用户访问
3. 运行repair_allow_data_loss修复
4. 修复完成后运行DBCC CHECKDB确定没有问题
5. 将数据库更改为多用户访问
（一）前言
如果我们没有数据库备份，无法使用页面还原，那么我们就需要用repair_allow_data_loss来修复（会有数据损失，而且不一定所有的都是可以恢复的）一般来说，最小的修复级别是repair_allow_data_loss。
（二）关于DBCC CHECKxxx系列命令
在T-SQL中，DBCC是“数据库控制台命令”的首字母缩写，是执行多种任务的命令。这些任务主要是验证和维护数据库类型的任务。
一些DBCC命令（如下图所示）用于内部只读数据库快照。这意味着数据库引擎创建一个数据库快照，并使其处于事务一致状态。然后，DBCC命令针对该快照执行检查。执行完成后，快照将被删除。
1. DBCC CHECKALLOC
DBCC CHECKALLOC命令检查指定数据库的磁盘空间分配结构的一致性。
2. DBCC CHECKCATALOG
检查指定数据库内的目录一致性。 数据库必须联机。
3. DBCC CHECKDB
（1）基本概念
通过执行下列操作检查指定数据库中所有对象的逻辑和物理完整性：
- 对数据库运行 DBCC CHECKALLOCDBCC CHECKALLOC。
- 对数据库中的每个表和视图运行DBCC CHECKTABLE DBCC CHECKTABLE。
- 对数据库运行DBCC CHECKCATALOG DBCC CHECKCATALOG。
- 验证数据库中每个索引视图的内容。
- 使用 FILESTREAM 在文件系统中存储 varbinary(max) 数据时，验证表元数据和文件系统目录和文件之间的链接级一致性。
- 验证数据库中的 Service Broker 数据。
这意味着不必从 DBCC CHECKDB 单独运行 DBCC CHECKALLOC、DBCC CHECKTABLE 或 DBCC CHECKCATALOG 命令。 有关这些命令执行的检查的详细信息，请参阅官网上这些命令的说明。
（2）基本语法
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 } ]
[ , MAXDOP = number_of_processors ]
}
]
]（3）参数说明
database_name | database_id | 0
要为其运行完整性检查的数据库的名称或 ID。 如果未指定，或者指定为 0，则使用当前数据库。 数据库名称必须符合标识符标识符规则。
NOINDEX
指定不对用户表的非聚集索引执行会占用很大系统开销的检查。 此选项将减少总执行时间。 NOINDEX 不影响系统表，因为总是对系统表索引执行完整性检查。
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
指定 DBCC CHECKDB 修复发现的错误。 仅将 REPAIR 选项作为最后手段使用。 指定的数据库必须处于单用户模式，才能使用以下修复选项之一。
REPAIR_ALLOW_DATA_LOSS
尝试修复报告的所有错误。 这些修复可能会导致一些数据丢失。
REPAIR_FAST
保留该语法只是为了向后兼容。 未执行修复操作。
REPAIR_REBUILD
执行不会丢失数据的修复。 此选项可能包括快速修复（如修复非聚集索引中缺少的行）以及更耗时的修复（如重新生成索引）。
此参数不修复涉及 FILESTREAM 数据的错误。
ALL_ERRORMSGS
显示针对每个对象报告的所有错误。 默认情况下显示所有错误消息。 指定或省略此选项都不起作用。 按对象 ID 对错误消息排序，从 tempdb 数据库生成的那些消息除外。
EXTENDED_LOGICAL_CHECKS
如果兼容性级别为 100 (SQL Server 2008) 或更高，则对索引视图、XML 索引和空间索引（如果存在）执行逻辑一致性检查。
有关详细信息，请参阅本文后面备注部分中的“对索引执行逻辑一致性检查”。
NO_INFOMSGS
取消显示所有信息性消息。
TABLOCK
使 DBCC CHECKDB 获取锁，而不使用内部数据库快照。 这包括一个短期数据库排他 (X) 锁。 TABLOCK 可使 DBCC CHECKDB 在负荷较重的数据库上运行得更快，但 DBCC CHECKDB 运行时会减少数据库上可获得的并发性。
ESTIMATEONLY
显示运行包含所有其他指定选项的 DBCC CHECKDB 时所需的 tempdb 空间估计量。 不执行实际数据库检查。
PHYSICAL_ONLY
将检查限制为页和记录标头的物理结构完整性以及数据库的分配一致性。 设计该检查是为了以较小的开销检查数据库的物理一致性，但它还可以检测会危及用户数据安全的残缺页、校验和错误以及常见的硬件故障。
DBCC CHECKDB 完成运行所需的时间可能比早期版本要长得多。 出现此现象的原因是：
- 逻辑检查更加全面。
- 要检查的某些基础结构更为复杂。
- 引入了许多新的检查以包含新增功能。
因此，使用 PHYSICAL_ONLY 选项可能会大幅减少对较大数据库运行 DBCC CHECKDB 所需的时间，所以对需要频繁检查的生产系统，建议使用此选项。 我们仍然建议完整地定期执行 DBCC CHECKDB。 这些运行的执行频率取决于各业务和生产环境特定的因素。
此参数始终表示 NO_INFOMSGS，不能与任何一个修复选项一同使用。
DATA_PURITY
使 DBCC CHECKDB 检查数据库中是否存在无效或越界的列值。 例如，DBCC CHECKDB 检测日期和时间值大于或小于 datetime 数据类型的可接受范围的列，或者小数位数或精度值无效的 decimal 或近似 numeric 数据类型列 。
默认情况下将启用列值完整性检查，并且不需要使用 DATA_PURITY 选项。 对于从 SQL Server 的早期版本升级的数据库，默认情况下不启用列值检查，直到 DBCC CHECKDB WITH DATA_PURITY 已在数据库中正确运行为止。 然后，DBCC CHECKDB 将默认检查列值完整性。 有关从 SQL Server 的早期版本升级数据库会对 CHECKDB 有何影响的详细信息，请参阅本主题的“备注”部分。
MAXDOP
适用对象：SQL Server（SQL Server 2014 (12.x) SP2 和更高版本）。
（三）实际操作案例
下面我们就使用DBCC CHECKDH repair_allow_data_loss来修复损坏的数据库。假定我们要修复的数据库名为Corrupt2022Fatal
1. 将数据库状态改为紧急模式
---将数据库状态改为紧急模式
ALTER DATABASE Corrupt2022Fatal SET EMERGENCY
GO
2. 将数据库改为单用户访问
--将数据库改为单用户访问
ALTER DATABASE Corrupt2022Fatal SET SINGLE_USER
GO 
3. 运行repair_allow_data_loss修复
--运行repair_allow_data_loss修复
DBCC CHECKDB(Corrupt2022Fatal,repair_allow_data_loss)
Go
4. 修复完成后运行DBCC CHECKDB确定没有问题
---修复完成后运行DBCC CHECKDB确定没有问题
DBCC CHECKDB with NO_INFOMSGS;
Go 
5. 将数据库更改为多用户访问
--将数据库更改为多用户访问
ALTER DATABASE Corrupt2022Fatal SET MULTI_USER;
go 
如果建议的修复级别为REPAIR_REBUILD，您可以放心执行，不会有数据损失 。 这包括快速修复（如修复非聚集索引中缺少的行）以及更耗时的修复（如重新生成索引）。
| 注意事项： |
|---|
| 仅将 REPAIR 选项作为最后手段使用。 若要修复错误，建议您通过备份进行还原。 修复操作不会考虑表本身或表之间可能存在的任何约束。如果指定的表与一个或多个约束有关，建议您在修复操作后运行 DBCC CHECKCONSTRAINTS。如果必须使用 REPAIR，则运行不带有修复选项的 DBCC CHECKDB 来查找要使用的修复级别。如果使用 REPAIR_ALLOW_DATA_LOSS 级别，则建议您在运行带有此选项的 DBCC CHECKDB 之前备份数据库。 |
