資料庫損壞是每一個 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 為什麼定期健康檢查至關重要
人們需要定期進行健康檢查，以便及早發現潛在疾病。同樣，資料庫也需要定期進行健康檢查：
- 及早發現潛在的腐敗並及時處理，防止問題變得嚴重和普遍，從而給企業帶來災難性的後果。
- 確保資料庫以最佳效能運作。
- 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.or
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 企業版提供頁面還原功能，無需完整資料庫還原即可修復特定損壞頁面。這項高級技術需要完整的復原模型和當前日誌備份。
逐步頁面恢復過程：
- 識別損壞的頁面 來自 CHECKDB 錯誤訊息（例如，頁 1:256）
- 進行目前日誌備份 捕獲最近的交易：
BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'- 恢復損壞的頁面 從most 最近的完整備份：
RESTORE DATABASE YourDatabase PAGE = '1:256'
FROM DISK = 'C:\Backups\YourDB_Full.bak'- 應用差異備份 （如果可供使用的話）：
RESTORE DATABASE YourDatabase PAGE = '1:256'
FROM DISK = 'C:\Backups\YourDB_Diff.bak'- 應用所有日誌備份 按順序，包括剛剛建立的：
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'- 進行最後的日誌備份和恢復 使頁面變成目前頁面：
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 data5.3 索引損壞快速修復
索引損壞通常對重建索引結構而不影響底層表資料的重建操作反應良好：
ALTER INDEX ALL ON YourTable REBUILD這種方法對於非聚集索引損壞特別有效，因為重建會從來源表資料重新產生索引頁，從而有效地消除損壞，同時保留所有原始資訊。
6. 使用 REPAIR_REBUILD 和 REPAIR_ALLOW_DATA_LOSS
如果前面的方法都失敗或不可行，可以使用REPAIR_REBUILD和REPAIR_ALLOW_DATA_LOSS選項來修復資料庫。
6.1 REPAIR_REBUILD（更安全的選項）：
- 用於： 索引損壞和輕微分配錯誤
- 數據安全： 嘗試在不刪除資料的情況下修復損壞
- 風險等級： 低 – 預計不會遺失數據
- 典型場景： 非聚集索引損壞，輕微元資料問題
- 命令範例：
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_fixed.mdf （無記錄 lost) |
| SQL Server 2014 | 錯誤10_2.mdf （訊息 8909 後跟訊息 8939）（6000 筆記錄（50%）lost 附 REPAIR_ALLOW_DATA_LOSS） | 錯誤10_2_fixed.mdf （僅 100 筆記錄 lost) |
| SQL Server 2014 | Error7.mdf文件 （100 筆記錄 lost 附 REPAIR_ALLOW_DATA_LOSS） | 錯誤7_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_fixed.mdf |
| SQL Server 2014 | 錯誤1_1.mdf （連續 Msg 824 錯誤） | 錯誤1_1_固定.mdf |
| SQL Server 2014 | 錯誤1_2.mdf （（訊息 824 後跟訊息 7909） | 錯誤1_2_fixed.mdf |
| SQL Server 2014 | 錯誤4_1.mdf （訊息 8992，隨後是訊息 3852） | 錯誤4_1_fixed.mdf |
| SQL Server 2014 | 錯誤4_2.mdf （訊息 8992，隨後是訊息 3852） | 錯誤4_2_fixed.mdf |
| SQL Server 2014 | 錯誤5.mdf （訊息 8945） | 錯誤5_fixed.mdf |
| SQL Server 2014 | 錯誤6.mdf （訊息 2510） | 錯誤6_fixed.mdf |
| SQL Server 2014 | 錯誤2.mdf （訊息 2575） | 錯誤2_fixed.mdf |
| SQL Server 2014 | 錯誤11.mdf （訊息 8905） | 錯誤11_fixed.mdf |
| SQL Server 2014 | 錯誤3.mdf （訊息 5028） | 錯誤3_fixed.mdf |
| SQL Server 2014 | Error8.mdf文件 （訊息 5125） | Error8_固定.mdf |
| SQL Server 2014 | 錯誤9.mdf （訊息 3313） | 錯誤9_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 將在各種情況下失敗，包括：
在這些情況下，我們需要更專業的工具來幫助我們修復資料庫中的損壞。
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 從嚴重腐敗中恢復過來
針對嚴重情況的進階功能：
- 從物理損壞的儲存中恢復
- 從格式化的磁碟機或崩潰的系統中恢復
- 從磁碟映像、備份檔案、虛擬機器磁碟檔案、速度恢復rary 檔等
9.4 何時考慮專業解決方案
- 最近沒有可用的備份
- DBCC CHECKDB 失敗
- 嚴重的貪腐情況
- 處理關鍵業務數據
- 當時間緊迫時
- 當需要最大限度恢復時
10. 常見問題
10.1 基本使用問題
Q：我應該多久運行一次 DBCC CHECKDB？
A: 對於關鍵生產資料庫，請每週執行 CHECKDB。對於高交易量系統，請考慮使用 PHYSICAL_ONLY 選項進行每日檢查，並每週進行一次全面檢查。開發資料庫可以每月檢查一次。
Q：我可以在即時生產資料庫上執行 DBCC CHECKDB 嗎？
A: 是的，DBCC CHECKDB 可以在線上資料庫上運行，而不會阻塞使用者。但是，它會消耗大量資源，因此請將其安排在活動較少的時段，並監控系統效能。
Q：CHECKDB 和 CHECKTABLE 有什麼不同？
A: CHECKDB 檢查整個資料庫，而 CHECKTABLE 則專注於單一資料表。使用 CHECKTABLE 進行 tar進行故障排除或需要檢查特定表而不掃描整個資料庫時。
10.2 績效和資源問題
Q：為什麼 DBCC CHECKDB 在我的大型資料庫上運行需要這麼長時間？
A: CHECKDB 的持續時間取決於資料庫大小、硬體效能和所使用的選項。使用 PHYSICAL_ONLY 可加快檢查速度，或使用 NOINDEX 跳過非聚集索引。建議在維護時段內使用專用資源運作。
Q：CHECKDB 需要多少 tempdb 空間？
A: 通常，在 CHECKDB 作業期間，為 tempdb 指派資料庫大小的 10-15%。使用 ESTIMATEONLY 選項可獲得精確的估算值： DBCC CHECKDB('YourDB') WITH ESTIMATEONLY
Q：我可以取消正在執行的 CHECKDB 操作嗎？
A: 是的，您可以使用會話 ID 上的 KILL 命令取消 CHECKDB。但是，取消操作不會提供有關資料庫完整性的信息，您需要稍後再次執行該操作。
10.3 錯誤處理問題
Q：CHECKDB 發現錯誤 – 我應該驚慌嗎？
A: 不要驚慌，要迅速採取行動。首先，確定 CHECKDB 是否成功完成但發現了損壞，或者 CHECKDB 本身是否運行失敗。檢查錯誤是否僅影響非聚集索引（較不嚴重）或表格資料（更嚴重）。
Q：什麼時候應該使用 REPAIR_ALLOW_DATA_LOSS？
A: 只有在沒有可用備份且資料遺失比資料庫完全遺失更可接受的情況下，才應將其作為絕對的最後手段。請務必先嘗試從備份進行恢復，因為修復作業可能會導致永久性資料遺失。
Q：「資料庫一致性錯誤」和「分配錯誤」是什麼意思？
A: 分配錯誤會影響 SQL Server 追蹤磁碟空間使用情況，而一致性錯誤則指示資料或索引結構有問題。兩者都需要注意，但一致性錯誤通常更直接地影響資料的可訪問性。
10.4 備份與復原問題
Q：我應該在備份上執行 CHECKDB 嗎？
A: 當然！將備份還原到測試伺服器後，請執行 CHECKDB。這將驗證備份的完整性，並確保您可以真正從損壞中還原資料。如果可能，請自動執行此程序。
Q：我的備份也損壞了──現在怎麼辦？
A: 嘗試使用較舊的備份，直到找到乾淨的備份。如果沒有乾淨的備份，請考慮使用專業的復原解決方案，例如 DataNumen SQL Recovery. 記錄腐敗時間表以防止將來再次發生。
Q：無需完全恢復資料庫，頁面恢復可以修復損壞嗎？
A: 是的，但僅限於 SQL Server 企業版，具有完整復原模式和目前日誌備份。頁面恢復適用於孤立的頁面損壞，但需要按照正確的程序謹慎執行。
10.5 故障排除問題
Q：CHECKDB 因「空間不足」錯誤而失敗 - 我該怎麼辦？
A: 釋放 tempdb 空間，將 tempdb 移至更快的儲存空間，或使用 TABLOCK 選項來減少 tempdb 的使用率。考慮使用 NOINDEX 或 PHYSICAL_ONLY 執行 CHECKDB 以減少資源需求。
Q：如何從 CHECKDB 輸出中辨識哪個表有損壞？
A: 在錯誤訊息中尋找「物件 ID」號，然後使用： SELECT OBJECT_NAME(object_id) 尋找表名。錯誤訊息還包含頁碼和槽號，以便精確識別位置。
Q：硬體問題會導致 CHECKDB 報告誤報嗎？
A: 是的，硬體故障（尤其是儲存裝置）可能會導致間歇性損壞，這些損壞會在 CHECKDB 運作期間出現和消失。如果錯誤不一致，請檢查您的 I/O 子系統並執行多個檢查以確認其模式。
10.6 進階配置問題
Q：哪些追蹤標誌可以提高 CHECKDB 效能？
A: 追蹤標誌 2562 可以透過將 CHECKDB 作為單一批次運行來提升效能。當資料庫檔案位於不同磁碟時，追蹤標誌 2549 會有所幫助。請謹慎使用這些標誌，並先在非生產環境中進行測試。
Q：如何自動化 CHECKDB 監控和警報？
A: 使用 SQL Server 代理針對錯誤號 8930、8939 及其他錯誤發出警報。實作日誌解析以提取 CHECKDB 結果，並針對任何損壞發現建立通知。考慮使用維護解決方案框架，例如 Ola Hallengren 的腳本。
Q：我應該使用 EXTENDED_LOGICAL_CHECKS 選項嗎？
A: 只有當您懷疑存在複雜的邏輯損壞且效能開銷足夠大時才需要這樣做。此選項會對索引視圖、XML 索引和空間索引執行額外檢查，但會顯著增加執行時間。
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。 參考
- 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 - Microsoft Learn。 “解決 DBCC CHECKDB 報告的資料庫一致性錯誤。” SQL Server 文档. 微軟公司。
https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors