目录 隐藏

数据库损坏是每一个 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 basic DBCC CHECKDB command include three common variations:

(1) Check the current database (no parameters):

DBCC CHECKDB

(2) Check a database by name:

DBCC CHECKDB ('YourDatabaseName')

(3) Check a database by ID:

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

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

Below is a screenshot of running DBCC CHECKDB in SQL Server 管理工作室 (SSMS):

A screenshot of running DBCC CHECKDB in SQL Server Management Studio (SSMS), including the output results.

3.3 Complete Options

Below are the complete options for DBCC CHECKDB:

分类 附加选项 描述 DBCC CHECKDB example
维修选项 REPAIR_REBUILD Repairs without data loss (e.g., index rebuilds) DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
REPAIR_FAST No repair. Backward compatibility only DBCC CHECKDB ('MyDB', REPAIR_FAST)
REPAIR_ALLOW_DATA_LOSS Repairs all errors (may cause data loss) DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
范围控制 NOINDEX Skips nonclustered index checks DBCC CHECKDB ('LargeDB', NOINDEX)
PHYSICAL_ONLY Checks only physical storage integrity (pages/records) DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
DATA_PURITY Checks for logical column-value errors (e.g., invalid dates) DBCC CHECKDB ('OldDB', DATA_PURITY)
EXTENDED_LOGICAL_CHECKS Deep logical checks (indexed views, XML/spatial indexes) DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
输出控制 ALL_ERRORMSGS Shows all errors (default: 200 per object) DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
NO_INFOMSGS Hides informational messages DBCC CHECKDB ('MyDB', NO_INFOMSGS)
性能 TABLOCK Uses table locks (reduces TempDB usage but blocks writes) DBCC CHECKDB ('BigDB', TABLOCK)
MAXDOP = number Overrides parallelism settings DBCC CHECKDB ('MyDB', MAXDOP = 2)
公用事业 ESTIMATEONLY Estimates TempDB space needed. (no actual check) DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. 理解你的结果

DBCC CHECKDB will produce different results based on whether its execution completes successfully or not. Let’s explain them in detail.

4.1 CHECKDB Execution Completes Successfully

If DBCC CHECKDB execution completes successfully, it will report different types of results depending on your database’s health status.

4.1.1 No Issues Found

If DBCC CHECKDB does not find any issues, you’ll see output similar to:

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

This result indicates your database maintains perfect integrity across all checked structures.

4.1.2 Found Corruption Errors

Whenever DBCC CHECKDB detects a corruption error, it will report an error message with the following structure:
A detailed explanation of the DBCC CHECKDB error message structure, including the meaning of each part.Severity Level Guide:

  • 16-19级: User-correctable errors, often minor corruption
  • 20-24级: System errors, serious corruption requiring immediate attention
  • 级别25: Fatal errors, database may be inaccessible

常见错误包括:

  • Page checksum failures (message 824)
  • Allocation errors (message 8928)
  • Index consistency problems (message 8964)

Understanding the message structure helps prioritize response actions and determine appropriate recovery strategies.

4.1.3 Common Informational and Warning Messages

Not all DBCC CHECKDB output indicates serious problems. It may also output some informational and warning messages, including:

  • Repair statements – Messages that suggest repair commands for fixing minor issues
  • Allocation warnings – Warnings about space allocation that don’t affect data access
  • Performance recommendations – Suggestions for index maintenance and optimization
  • 信息通知 – General status messages that don’t require immediate action

These messages provide valuable maintenance guidance while distinguishing between critical corruption requiring immediate action and minor issues that can be addressed during regular maintenance windows.

Example warning message:

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 Execution Aborts

If CHECKDB aborts during its execution due to various reasons, it will report an error message and add an error log with the state code below:

描述
0 Error number 8930 was raised. This indicates a corruption in metadata that terminated the DBCC command.
1 Error number 8967 was raised. There was an internal DBCC error.
2 A failure occurred during emergency mode database repair.
3 This indicates a corruption in metadata that terminated the DBCC command.
4 An assert or access violation was detected.
5 An unknown error occurred that terminated the DBCC command.

Example error message:

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'.

Example error log:

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.

In such a case, you can try alternative advanced options such as DataNumen SQL Recovery to fix the corruption in your database.

5. Fixing Corruption Errors

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

When DBCC CHECKDB identifies corruption errors, restoring from a clean backup represents the safest and most reliable solution. This approach guarantees data integrity while eliminating underlying corruption causes. Before restoring, verify backup integrity using 仅恢复验证 commands, and consider point-in-time recovery options to minimize data loss. Document the corruption details for root cause analysis, as hardware issues or software bugs may require additional attention to prevent recurrence.

5.2 页面级损坏解决方案

对于影响小部分数据的孤立页面损坏, SQL Server Enterprise Edition offers page restore capabilities that repair specific damaged pages without full database restoration. This advanced technique requires full recovery model and current log backups.

Step-by-step page restore process:

  1. Identify the corrupted page from CHECKDB error message (e.g., page 1:256)
  2. Take a current log backup to capture recent transactions:
BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'
  1. Restore the corrupted page from the most recent full backup:
RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'
  1. Apply differential backup (如果可供使用的话):
RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'
  1. Apply all log backups in sequence, including the one just created:
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'
  1. Take a final log backup and restore to bring the page current:
BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

Alternative for non-critical data: If corruption affects non-critical data, you might export unaffected rows to new tables before rebuilding corrupted structures:

-- 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. Use REPAIR_REBUILD and REPAIR_ALLOW_DATA_LOSS

If the previous methods all fail or are not feasible, you can use the REPAIR_REBUILD and REPAIR_ALLOW_DATA_LOSS options to repair the database.

6.1 REPAIR_REBUILD (Safer Option):

  • 用于: Index corruption and minor allocation errors
  • 数据安全: Attempts corruption fixes without data deletion
  • 风险等级: Low – no data loss expected
  • 典型场景: Non-clustered index corruption, minor metadata issues
  • Command example: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Last Resort):

  • 用于: Severe corruption when backups are unavailable
  • 数据安全: May delete corrupted data to restore database functionality
  • 风险等级: High – permanent data loss possible
  • 典型场景: Page corruption, system table damage, allocation chain errors
  • Command example: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Best Practices for Both Options:

  • 总是测试 repair operations on database copies when possible
  • Always back up before running these options
  • 记录所有更改 for compliance and troubleshooting purposes
  • Set database to single-user mode before running repair operations

6.4 Repair Results

6.4.1 Repair Succeeds but Data Lost

Sometimes the repair with the REPAIR_ALLOW_DATA_LOSS 修复 option will succeed, but some data are lost after the repair.

Below is a sample message:

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.

样本

SQL Server 版本 损坏的 MDF 文件 MDF文件修复 DataNumen SQL Recovery
SQL Server 2014 Error7.mdf (100 records lost with REPAIR_ALLOW_DATA_LOSS) Error7_fixed.mdf (Only one record lost with REPAIR_ALLOW_DATA_LOSS)

DBCC fixes the database by abandoning some damaged records, but actually, most of them can be recovered via DataNumen SQL Recovery.

6.4.2 Repair Failed

If repair failed, it will output an error message.

以下是一些示例:

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.
DBCC results for ‘SalesDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘SalesDatabase’.
Msg 7909, Level 20, State 1, Line 4
The emergency-mode repair failed.You must restore from backup.
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.

Sample Files

SQL Server 版本 损坏的 MDF 文件 MDF文件修复 DataNumen SQL Recovery
SQL Server 2014 错误3.mdf (CHECKDB returns Msg 5028) Error3_fixed.mdf
SQL Server 2014 Error8.mdf (CHECKDB returns Msg 5125) Error8_固定.mdf

6. 最佳实践

6.1 安排定期 CHECKDB 操作

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

6.2 绩效影响管理

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

6.3 维护窗口规划

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

6.4 自动监控和警报

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

7. DBCC CHECKTABLE:轻量级替代方案

7.1 何时使用 CHECKTABLE 而不是 CHECKDB

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

7.2 DBCC CHECKTABLE 语法和示例

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

DBCC CHECKTABLE('YourTable')

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

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

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

7.3 大型数据库的性能优势

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

8. 当 CHECKDB 失败时

DBCC CHECKDB will fail in various scenarios, including:

In these scenarios, we need a more professional tool to help us fix the corruptions in the database.

8.1简介 DataNumen SQL Recovery

DataNumen SQL Recovery provides more advanced capabilities:

  • 最佳恢复率 在这个行业。
  • Recover severely corrupted database files.
  • Recover all database objects, including tables, indexes, views, triggers, rules, and defaults.
  • 恢复存储过程、标量函数、内联表值函数和多语句表值函数。
  • Recover permanently deleted records.
  • Decrypt encrypted objects in SQL Server 数据库。
  • Repair MDF files in batch.
  • 全面的修复选项。
  • 高级日志记录和报告。
  • 支持所有人 SQL Server 版本。
  • 技术支持可用性
  • 定期更新和改进

8.2 成功率比较

恢复成功率差异很大:

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

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

A comparison chart of recovery rates between DataNumen SQL Recovery and other competitors, including DBCC CHECKDB & CHECKTABLE.

8.3 从严重腐败中恢复

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

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

8.5 何时考虑专业解决方案

  • No recent backup availability
  • DBCC CHECKDB fails
  • Severe corruption scenarios
  • Dealing with critical business data
  • 时间紧迫
  • 当最大程度的恢复至关重要时

9。 常见问题解答

9.1 Basic Usage Questions

Q: How often should I run DBCC CHECKDB?

A: For critical production databases, run CHECKDB weekly. For high-transaction systems, consider daily checks using PHYSICAL_ONLY option, with full checks weekly. Development databases can be checked monthly.

Q: Can I run DBCC CHECKDB on a live production database?

A: Yes, DBCC CHECKDB can run on online databases without blocking users. However, it consumes significant resources, so schedule it during low-activity periods and monitor system performance.

Q: What’s the difference between CHECKDB and CHECKTABLE?

A: CHECKDB examines the entire database, while CHECKTABLE focuses on individual tables. Use CHECKTABLE for targeted troubleshooting or when you need to check specific tables without scanning the whole database.

9.2 Performance and Resource Questions

Q: Why is DBCC CHECKDB taking so long on my large database?

A: CHECKDB duration depends on database size, hardware performance, and options used. Use PHYSICAL_ONLY for faster checks, or NOINDEX to skip non-clustered indexes. Consider running during maintenance windows with dedicated resources.

Q: How much tempdb space does CHECKDB need?

A: Generally, allocate 10-15% of your database size for tempdb during CHECKDB operations. Use ESTIMATEONLY option to get precise estimates: DBCC CHECKDB('YourDB') WITH ESTIMATEONLY

Q: Can I cancel a running CHECKDB operation?

A: Yes, you can cancel CHECKDB using the KILL command on the session ID. However, canceling provides no information about database integrity, and you’ll need to run it again later.

9.3 Error Handling Questions

Q: CHECKDB found errors – should I panic?

A: Don’t panic, but act quickly. First, determine if CHECKDB completed successfully but found corruption, or if CHECKDB itself failed to run. Check if errors affect only non-clustered indexes (less critical) or table data (more serious).

Q: When should I use REPAIR_ALLOW_DATA_LOSS?

A: Only as an absolute last resort when you have no usable backups and data loss is acceptable compared to total database loss. Always try restoring from backup first, as repair operations can cause permanent data loss.

Q: What does “consistency errors in database” vs “allocation errors” mean?

A: Allocation errors affect how SQL Server tracks disk space usage, while consistency errors indicate problems with data or index structures. Both require attention, but consistency errors typically impact data accessibility more directly.

9.4 Backup and Recovery Questions

Q: Should I run CHECKDB on my backups?

A: Absolutely! Run CHECKDB after restoring backups to test servers. This verifies backup integrity and ensures you can actually recover from corruption. Automate this process if possible.

Q: My backup is also corrupted – what now?

A: Try older backups until you find a clean one. If no clean backups exist, consider professional recovery solutions like DataNumen SQL Recovery. Document the corruption timeline to prevent future occurrences.

Q: Can page restore fix corruption without full database recovery?

A: 是的,但仅限于 SQL Server Enterprise Edition with full recovery model and current log backups. Page restore works for isolated page corruption but requires careful execution following proper procedures.

9.5 Troubleshooting Questions

Q: CHECKDB is failing with “out of space” errors – what can I do?

A: Free up tempdb space, move tempdb to faster storage, or use TABLOCK option to reduce tempdb usage. Consider running CHECKDB with NOINDEX or PHYSICAL_ONLY to reduce resource requirements.

Q: How do I identify which table has corruption from CHECKDB output?

A: Look for “object ID” numbers in error messages, then use: SELECT OBJECT_NAME(object_id) to find table names. Error messages also include page and slot numbers for precise location identification.

Q: Can hardware issues cause CHECKDB to report false positives?

A: Yes, failing hardware (especially storage) can cause intermittent corruption that appears and disappears between CHECKDB runs. If errors are inconsistent, investigate your I/O subsystem and run multiple checks to confirm patterns.

9.6 Advanced Configuration Questions

Q: What trace flags can improve CHECKDB performance?

A: Trace flag 2562 can improve performance by running CHECKDB as a single batch. Trace flag 2549 helps when database files are on separate disks. Use these carefully and test in non-production first.

Q: How do I automate CHECKDB monitoring and alerting?

A: 使用 VHDL 语言编写 SQL Server Agent alerts for error numbers 8930, 8939, and others. Implement log parsing to extract CHECKDB results, and create notifications for any corruption discoveries. Consider using maintenance solution frameworks like Ola Hallengren’s scripts.

Q: Should I use EXTENDED_LOGICAL_CHECKS option?

A: Only if you suspect complex logical corruption and have adequate performance overhead. This option performs additional checks on indexed views, XML indexes, and spatial indexes but significantly increases execution time.

10. 结论

10.1 要点总结

10.1.1 基本 DBCC CHECKDB 命令回顾

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

10.1.2 关键最佳实践提醒

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

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

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

11。 参考

  1. Microsoft Learn. “DBCC CHECKDB (Transact-SQL).” SQL Server 文件记录. Microsoft Corporation.
    https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
  2. Microsoft Learn. “Troubleshoot database consistency errors reported by DBCC CHECKDB.” SQL Server 文件记录. Microsoft Corporation.
    https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors