DBCC CHECKDB：MS 完整指南 SQL Server 数据库健康（2025）

数据库损坏是每一个 SQL Server 管理员的噩梦。当关键业务数据变得无法访问或不可靠时，cost 后果可能非常严重。本指南涵盖了使用 DBCC CHECKDB 维护数据库健康并防止数据库损坏所需的所有知识，以及在标准工具不足时提供的高级恢复解决方案。

1. 的重要性 SQL Server 数据库健康

1.1 什么是数据库损坏 Cost业务

今天，most 企业将关键数据存储在数据库中。一旦发生数据库损坏，后果将是灾难性的：

• 财务损失 每年因数据丢失造成的损失平均为 2.3 万美元，主要原因是硬件故障和损坏（EMC 公司）
• 企业倒闭率 研究表明，50% 的小型企业因硬件故障而遭遇数据丢失，在两年内倒闭，而 94% 的遭遇灾难性数据丢失的企业根本无法生存
• 数据损坏频率 每年影响 20% 的关键任务应用程序，导致业务连续性中断（Gartner 研究）
• 硬件相关损坏 在所有数据丢失事件中，硬盘崩溃和系统故障占 67%，其中 40% 的数据丢失直接归因于硬件故障
• 软件损坏 costs 根据严重程度和范围，损失从数千美元到数百万美元不等，82% 的企业遭遇计划外停电，其中腐败是主要原因

1.2 为什么定期健康检查至关重要

人们需要定期进行健康检查，以便及早发现潜在疾病。同样，数据库也需要定期进行健康检查：

1. 及早发现潜在的腐败并及时处理，防止问题变得严重和普遍，从而给企业带来灾难性的后果。
2. 确保数据库以最佳性能运行。
3. cost 主动数据库健康检查的发生率远低于数据库灾难发生后的被动数据恢复的发生率。

1.3 数据库完整性命令介绍

SQL Server 提供了几个用于维护数据库健康的内置命令， DBCC 检查数据库 作为 most 全面的完整性检查工具。这些命令协同工作，验证数据库结构的各个方面，从单个表到整个数据库的一致性，形成一套完整的维护策略，确保数据安全且易于访问。

2.什么是DBCC CHECKDB

DBCC 检查数据库 is SQL Server验证数据库完整性和识别损坏问题的主要工具。

• 它是一个 T-SQL 语句，而不是 GUI 工具。
• 您可以通过常用方法执行它，例如 SQL Server 管理工作室（SSMS）， SQL Server 代理、SQLCMD 等

2.1 CHECKDB 在你的数据库中实际检查什么

运行 DBCC CHECKDB 时，该命令会对数据库结构执行多个验证层：

• 页面校验和验证 检测物理损坏和硬件相关问题
• 索引一致性验证 确保正确的数据检索和查询性能
• 分配结构检查 确认准确的空间使用情况和页面分配
• 参照完整性检查 相关表和外键关系之间
• 系统表一致性验证 确保 SQL Server的内部元数据仍然可靠
• 数据页链接验证 确认页面链的完整性
• 数据库模式一致性 验证对象定义和依赖关系

这些全面的检查涵盖用户数据和系统结构，让您可以全面了解数据库的健康状况。

3. 运行 DBCC CHECKDB：分步操作

3.1先决条件

以下是执行任何 DBCC CHECKDB 操作之前的检查清单：

• 完整的数据库备份 – 在运行完整性检查之前创建完整备份，作为发现损坏或需要修复操作时的安全网。
• 适当的权限 – 您需要 sysadmin 或 db_owner 权限才能执行 DBCC CHECKDB 命令
• 充足的系统资源：
  • 内存：数据库大小的 25%
  • Tempdb 空间：数据库大小的 10-15%
  • CPU：维护期间可用性为 50-70%
  • I/O：预计读取操作较多
• 数据库可访问性 – 验证您的数据库是否可访问且不处于受限状态，因为 CHECKDB 需要对所有数据库页面具有读取权限

3.2 基本命令

该米ost 基本的 DBCC CHECKDB 命令包括三种常见的变体：

（1）检查当前数据库（不带参数）：

DBCC CHECKDB

（2）按名称检查数据库：

DBCC CHECKDB ('YourDatabaseName')

(3) 通过 ID 检查数据库：

DBCC CHECKDB(5)  -- Replace 5 with your database ID

此基本命令对指定数据库执行完整的完整性检查，检查所有表、索引和系统结构。对于标准名称不包含空格的数据库，可以省略引号。该命令将运行直至完成，并显示进度消息和最终结果。此基本语法非常适合较小的数据库或您有充足的维护时间的情况。

下面是运行 DBCC CHECKDB 的屏幕截图 SQL Server 管理工作室 (SSMS)：

3.3 完整选项

以下是 DBCC CHECKDB 的完整选项：

分类	附加选项	描述	DBCC CHECKDB 示例
维修选项	REPAIR_REBUILD	无数据丢失的修复（例如索引重建）	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	无需修复。仅向后兼容	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	修复所有错误（可能导致数据丢失）	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
范围控制	NOINDEX	跳过非聚集索引检查	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	仅检查物理存储完整性（页面/记录）	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	检查逻辑列值错误（例如无效日期）	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	深度逻辑检查（索引视图、XML/空间索引）	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
输出控制	ALL_ERRORMSGS	显示所有错误（默认值：每个对象 200 个）	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	隐藏信息消息	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
性能	TABLOCK	使用表锁（减少 TempDB 使用但阻止写入）	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	覆盖并行度设置	DBCC CHECKDB ('MyDB', MAXDOP = 2)
公用事业	ESTIMATEONLY	估计所需的 TempDB 空间。（无需实际检查）	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. 理解你的结果

DBCC CHECKDB 执行是否成功，会产生不同的结果。让我们详细解释一下。

4.1 CHECKDB执行成功完成

如果 DBCC CHECKDB 执行成功完成，它将根据数据库的健康状态报告不同类型的结果。

4.1.1 未发现问题

如果 DBCC CHECKDB 没有发现任何问题，您将看到类似以下内容的输出：

CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

此结果表明您的数据库在所有检查的结构中都保持了完美的完整性。

4.1.2 发现损坏错误

每当 DBCC CHECKDB 检测到损坏错误时，它都会报告具有以下结构的错误消息：
严重程度指南：

• 16-19级： 用户可纠正的错误，通常是轻微损坏
• 20-24级： 系统错误、严重损坏需要立即关注
• 级别25： 致命错误，数据库可能无法访问

常见错误包括：

• 页面校验和失败（消息 824）
• 分配错误（消息 8928）
• 索引一致性问题（消息 8964）

了解消息结构有助于确定响应行动的优先级并确定适当的恢复策略。

4.1.3 常见信息和警告消息

并非所有 DBCC CHECKDB 输出都指示严重问题。它还可能输出一些信息性和警告消息，包括：

• 修复声明 – 建议修复命令以修复小问题的消息
• 分配警告 – 关于不影响数据访问的空间分配的警告
• 性能建议 – 索引维护和优化建议
• 信息通知 – 不需要立即采取行动的一般状态消息

这些消息提供了有价值的维护指导，同时区分了需要立即采取行动的严重损坏和可以在定期维护期间解决的小问题。

警告消息示例：

DBCC results for 'InventoryDatabase'.
Msg 2570, Level 16, State 3, Line 1
Page (2:8452), slot 17 in object ID 485577333, index ID 0, partition ID 72057594038845456, 
alloc unit ID 72057594042515968 (type "In-row data").
Column "ProductPrice" value is out of range for data type "decimal". Update column to a legal value.
There are 45892 rows in 1247 pages for object "Products".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Products' (object ID 485577333).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'InventoryDatabase'.

4.2 CHECKDB执行中止

如果CHECKDB在执行过程中由于各种原因中止，它将报告一条错误消息并添加一个错误日志，其中包含以下状态代码：

州	描述
0	出现错误号 8930。这表明元数据损坏，导致 DBCC 命令终止。
1	出现错误号 8967。出现内部 DBCC 错误。
2	紧急模式数据库修复期间发生故障。
3	这表明元数据损坏，从而终止了 DBCC 命令。
4	检测到断言或访问冲突。
5	发生未知错误，终止了 DBCC 命令。

错误消息示例：

Failed:(-1073548784) Executing the query "DBCC CHECKDB('InventoryDB') WITH NO_INFOMSGS" failed with the following error: "There is insufficient system memory to run this query.Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

或

2024-11-18 09:52:41.38 spid35 I/O error (bad page ID) detected during read at offset 0x00000024886000 in file 'C:\Data\MSSQL\DATA\SalesDatabase.mdf'.

错误日志示例：

11/15/2024 09:23:17,spid52,Unknown,DBCC CHECKDB (SalesDatabase) WITH all_errormsgs no_infomsgs executed by CORP\dbadmin terminated abnormally due to error state 3. Elapsed time: 1 hours 32 minutes 18 seconds.

在这种情况下，您可以尝试其他高级选项，例如 DataNumen SQL Recovery 修复数据库中的损坏。

5.修复损坏错误

5.1 备份和恢复：最安全的解决方法

当 DBCC CHECKDB 识别损坏错误时，从干净的备份中恢复是最安全和最有效的ost 可靠的解决方案。这种方法保证了数据完整性，同时消除了潜在的损坏原因。在恢复之前，请使用以下方法验证备份完整性： 仅恢复验证 命令，并考虑使用时间点恢复选项，以最大程度地减少数据丢失。记录损坏的详细信息以便进行根本原因分析，因为硬件问题或软件错误可能需要额外关注，以防止再次发生。

5.2 页面级损坏解决方案

对于影响小部分数据的孤立页面损坏， SQL Server 企业版提供页面还原功能，无需完整数据库还原即可修复特定损坏页面。这项高级技术需要完整的恢复模型和当前日志备份。

逐步页面恢复过程：

1. 识别损坏的页面 来自 CHECKDB 错误消息（例如，页面 1:256）
2. 进行当前日志备份 捕获最近的交易：

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'

3. 恢复损坏的页面 从most 最近的完整备份：

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'

4. 应用差异备份 （如果可供使用的话）：

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'

5. 应用所有日志备份 按顺序，包括刚刚创建的：

RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'

6. 进行最后的日志备份和恢复 使页面变为当前页面：

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

非关键数据的替代方案： 如果损坏影响非关键数据，您可以在重建损坏的结构之前将未受影响的行导出到新表：

-- Export good data to a new table
SELECT * INTO YourTable_Backup 
FROM YourTable 
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)

-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data

5.3 索引损坏快速修复

索引损坏通常对重建索引结构而不影响底层表数据的重建操作反应良好：

ALTER INDEX ALL ON YourTable REBUILD

这种方法对于非聚集索引损坏特别有效，因为重建会从源表数据重新生成索引页，从而有效地消除损坏，同时保留所有原始信息。

6. 使用 REPAIR_REBUILD 和 REPAIR_ALLOW_DATA_LOSS

如果前面的方法都失败或者不可行，可以使用REPAIR_REBUILD和REPAIR_ALLOW_DATA_LOSS选项来修复数据库。

6.1 修复_重建（更安全的选项）：

• 用于： 索引损坏和轻微分配错误
• 数据安全： 尝试在不删除数据的情况下修复损坏
• 风险等级： 低 – 预计不会丢失数据
• 典型场景： 非聚集索引损坏，轻微元数据问题
• 命令示例： DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS（最后手段）：

• 用于： 备份不可用时出现严重损坏
• 数据安全： 可以删除损坏的数据以恢复数据库功能
• 风险等级： 高 – 可能造成永久性数据丢失
• 典型场景： 页面损坏、系统表损坏、分配链错误
• 命令示例： DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 这些选项的最佳实践：

• 总是测试 尽可能修复数据库副本上的操作
• 始终备份 在运行这些选项之前
• 记录所有更改 出于合规性和故障排除目的
• 将数据库设置为单用户模式 运行修复操作之前

通常情况下，我们应该尝试 修复_重建 选项。如果失败，则尝试 REPAIR_ALLOW_DATA_LOSS 修复 选项。

6.4 REPAIR_ALLOW_DATA_LOSS 结果

6.4.1 修复成功但数据丢失

有时候 REPAIR_ALLOW_DATA_LOSS 修复 选项将会成功，但有些数据是ost 修复后。

以下是一些示例消息：

CHECKDB found 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
CHECKDB fixed 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Msg 8909, Level 16, State 1, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 45035996309880832 (type Unknown), page ID (1:553) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
The error has been repaired.
Msg 8939, Level 16, State 98, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 111464090777419776 (type Unknown), page (0:0). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -1.
Could not repair this error.

这是因为 DBCC CHECKDB 通过放弃一些损坏的记录来修复数据库，但实际上，most 其中仍可通过以下方式恢复 DataNumen SQL Recovery.

示例文件：

SQL Server 版本	损坏的 MDF 文件	MDF文件修复 DataNumen SQL Recovery
SQL Server 2014	错误10_1.mdf （消息 8909 后跟消息 8939）（600 条记录 lost 带有 REPAIR_ALLOW_DATA_LOSS）	错误10_1_固定.mdf （无记录 lost)
SQL Server 2014	错误10_2.mdf （消息 8909 后跟消息 8939）（6000 条记录（50%）lost 带有 REPAIR_ALLOW_DATA_LOSS）	错误10_2_固定.mdf （仅 100 条记录 lost)
SQL Server 2014	Error7.mdf （100 条记录 lost 带有 REPAIR_ALLOW_DATA_LOSS）	Error7_fixed.mdf （只有一条记录ost)

6.4.2 修复失败——考虑专业解决方案

If REPAIR_ALLOW_DATA_LOSS 修复 失败时，会输出一条或多条错误信息。

以下是一些示例：

DBCC results for ‘MyDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘MyDatabase’.
Msg 824, Level 24, State 2, Line 8
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xea8a9a2f; actual: 0x37adbff8). It occurred during a read of page (1:28) in database ID 39 at offset 0x00000000038000 in file ‘MyDatabase.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Msg 7909, Level 20, State 1, Line 8
The emergency-mode repair failed.You must restore from backup.

Msg 8992, Level 16, State 1, Line 8
Check Catalog Msg 3852, State 1: Row (object_id=69) in sys.objects (type=S ) does not have a matching row (object_id=69,column_id=1) in sys.columns.

Msg 8945, Level 16, State 1, Line 8
Table error: Object ID 41, index ID 1 will be rebuilt.
Could not repair this error.

Msg 2510, Level 16, State 17, Line 8
DBCC checkdb error: This system table index cannot be recreated.
Repair: The Nonclustered index successfully rebuilt for the object “sysidxstats” in database “MyDatabase”.

Msg 8921, Level 16, State 1, Line 8
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 8998, Level 16, State 2, Line 8
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 39 pages from (1:0) to (1:8087). See other errors for cause.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 2575, Level 16, State 1, Line 8
The Index Allocation Map (IAM) page (1:157) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.
Could not repair this error.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘sys.sysrscols’ (object ID 3).

Msg 8948, Level 16, State 3, Line 8
Database error: Page (1:295) is marked with the wrong type in PFS page (1:1). PFS status 0x70 expected 0x60.
The error has been repaired.
Msg 8905, Level 16, State 1, Line 8
Extent (1:296) in database ID 39 is marked allocated in the GAM, but no SGAM or IAM has allocated it.
The error has been repaired.

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.

Msg 5125, Level 24, State 2, Line 2
File ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.mdf’ appears to have been truncated by the operating system. Expected size is 5120 KB but actual size is 5112 KB.
Msg 3414, Level 21, State 1, Line 2
An error occurred during recovery, preventing the database ‘SalesDatabase’ (39:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

Msg 3313, Level 21, State 1, Line 2
During redoing of a logged operation in database ‘SalesDatabase’, an error occurred at log record ID (135:752:2). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.

在这些情况下，您需要使用专业的解决方案，例如 DataNumen SQL Recovery 修复你的数据库。

示例文件

SQL Server 版本	损坏的 MDF 文件	MDF文件修复 DataNumen SQL Recovery
SQL Server 2014	错误1_3.mdf （单条消息 824）	错误1_3_固定.mdf
SQL Server 2014	错误1_1.mdf （连续 Msg 824 错误）	错误 1_1_固定.mdf
SQL Server 2014	错误1_2.mdf （（消息 824 后跟消息 7909）	错误1_2_固定.mdf
SQL Server 2014	错误4_1.mdf （消息 8992，随后是消息 3852）	错误4_1_固定.mdf
SQL Server 2014	错误4_2.mdf （消息 8992，随后是消息 3852）	错误4_2_固定.mdf
SQL Server 2014	错误5.mdf （消息 8945）	Error5_fixed.mdf
SQL Server 2014	错误6.mdf （消息 2510）	Error6_fixed.mdf
SQL Server 2014	错误2.mdf （消息 2575）	Error2_fixed.mdf
SQL Server 2014	错误11.mdf （消息 8905）	Error11_fixed.mdf
SQL Server 2014	错误3.mdf （消息 5028）	Error3_fixed.mdf
SQL Server 2014	Error8.mdf （消息 5125）	Error8_固定.mdf
SQL Server 2014	错误9.mdf （消息 3313）	Error9_fixed.mdf

7. 最佳实践

7.1 安排定期 CHECKDB 操作

对关键生产数据库实施每周 DBCC CHECKDB 执行，并对高事务系统进行每日检查。将操作安排在使用率较低的时段，以最大程度地降低性能影响，并考虑根据数据库大小和维护时段在完整检查和 PHYSICAL_ONLY 选项之间轮换。通过以下方式自动安排 SQL Server 代理确保一致执行，同时提供集中监控和警报功能。

7.2 绩效影响管理

DBCC CHECKDB 操作会消耗大量系统资源，可能会影响并发用户活动。请监控检查期间的 CPU 利用率、内存消耗和磁盘 I/O，以了解性能影响模式。请考虑使用 NOINDEX 选项进行例行检查，并将完整验证保留在每月维护时段进行。请实施查询超时扩展和用户沟通策略，以管理完整性检查期间的预期。

7.3 维护窗口规划

将 DBCC CHECKDB 的调度与其他维护活动（例如备份操作、索引重建和统计信息更新）进行协调。避免重叠执行可能导致性能下降或超时问题的资源密集型操作。根据数据库大小增长预测规划维护时段，确保在数据量增加时有充足的时间进行完整的完整性验证。

7.4 自动监控和警报

配置 SQL Server 当 DBCC CHECKDB 发现损坏时，代理会立即发出警报通知管理员。实施日志解析解决方案，提取并分类完整性检查结果，从而实现趋势分析和主动问题识别。创建升级程序，定义不同损坏严重程度的响应时间范围和负责人员。

8. DBCC CHECKTABLE：轻量级替代方案

8.1 何时使用 CHECKTABLE 而不是 CHECKDB

DBCC CHECKTABLE 为单个表提供集中的完整性检查，非常适合 tar获得特定数据库对象的故障排除和维护。在调查特定表的性能问题、在完整数据库检查之间验证关键业务表，或当时间限制导致无法进行完整数据库验证时，请使用 CHECKTABLE。这种方法在大型数据库中尤其有用，因为完整 CHECKDB 操作超出了可用的维护窗口。

8.2 DBCC CHECKTABLE 语法和示例

基本 CHECKTABLE 命令 tar获取特定表：

DBCC CHECKTABLE('YourTable')

与 CHECKDB 类似，CHECKTABLE 支持多种选项，包括用于性能优化的 NOINDEX 和用于解决损坏问题的修复参数。您还可以指定架构名称以精确识别表：

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

本篇 targeted 方法允许进行粒度完整性验证，同时在工作时间内保持系统性能。

8.3 大型数据库的性能优势

CHECKTABLE 操作的完成速度比完整数据库检查快得多，因此可以更频繁地对关键表进行完整性验证。这种方法允许每日验证关键业务表，同时将全面的 CHECKDB 操作保留为每周或每月的计划。更低的资源消耗使 CHECKTABLE 非常适合在生产环境中执行，并且最大程度地减少对用户的影响。

9. 当 CHECKDB 失败时

DBCC CHECKDB 将在各种情况下失败，包括：

• DBCC CHECKDB 执行 异常终止
• DBCC CHECKDB 执行成功完成，但 维修选项 无法修复数据库。

在这些情况下，我们需要更专业的工具来帮助我们修复数据库中的损坏。

9.1简介 DataNumen SQL Recovery

DataNumen SQL Recovery 提供更高级的功能：

• 最佳恢复率 在这个行业。
• 恢复严重损坏的数据库文件。
• 恢复所有数据库对象，包括表、索引、视图、触发器、规则和默认值。
• 恢复存储过程、标量函数、内联表值函数和多语句表值函数。
• 恢复永久删除的记录。
• 解密加密对象 SQL Server 数据库。
• 批量修复 MDF 文件。
• 全面的修复选项。
• 高级日志记录和报告。
• 支持所有人 SQL Server 版本。
• 技术支持可用性
• 定期更新和改进

9.2 成功率比较

恢复成功率差异很大：

• DBCC CHECKDB 和 CHECKTABLE： 1.27% 平均回收率
• DataNumen: 92.6% 恢复率

以下是完整的竞争性比较：

9.3 从严重腐败中恢复

针对严重病例的高级功能：

• 从物理损坏的存储中恢复
• 从格式化的驱动器或崩溃的系统中恢复
• 从磁盘映像、备份文件、虚拟机磁盘文件、tempo 中恢复rary 文件等

9.4 何时考虑专业解决方案

• 最近没有可用的备份
• DBCC CHECKDB 失败
• 严重的腐败情况
• 处理关键业务数据
• 时间紧迫
• 当最大程度的恢复至关重要时

10。 常见问题解答

11. 结论

11.1 要点总结

11.1.1 基本 DBCC CHECKDB 命令回顾

掌握 DBCC CHECKDB 基本语法，用于全面数据库检查，利用 NOINDEX 和 PHYSICAL_ONLY 选项进行性能优化，并了解 CHECKTABLE tar获取表验证。这些基本命令构成了主动数据库维护的基础，能够实现早期损坏检测和系统完整性监控。

11.1.2 关键最佳实践提醒

在运行完整性检查之前，务必维护当前备份，根据数据库关键性安排定期的 CHECKDB 操作，并实施自动监控以便立即发出损坏警报。请记住，通过定期监控进行预防胜过被动应对，而专业的恢复解决方案在标准工具不足时，可以提供宝贵的备份选项。

11.2 何时使用 DBCC CHECKDB 与高级解决方案

使用 DBCC CHECKDB 进行常规完整性监控和轻微损坏修复，同时保留专业恢复工具用于超出内置修复功能的严重损坏情况。决策框架应考虑备份可用性、数据关键性、时间限制和损坏严重程度。当标准方法不足时，成功的数据库管理员会将常规 CHECKDB 监控与全面的备份策略以及对高级恢复选项的了解相结合。

12。 参考

1. Microsoft Learn。“DBCC CHECKDB (Transact-SQL)。” SQL Server 文件记录. 微软公司。
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn。“解决 DBCC CHECKDB 报告的数据库一致性错误。” SQL Server 文件记录. 微软公司。
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors