針對 DBCC CHECKB 報告的資料庫一致性錯誤進行疑難排解

本文說明如何針對命令所 DBCC CHECKDB 報告的錯誤進行疑難解答。

原始產品版本：SQL Server
原始 KB 編號： 2015748

徵兆

執行 DBCC CHECKDB （或類似 DBCC CHECKTABLE 的命令）時，會將類似下列命令的訊息寫入 SQL Server 錯誤記錄檔：

DBCC CHECKDB (mydb) executed by MYDOMAIN\theuser found 15 errors and repaired 3 errors.
Elapsed time: 0 hours 0 minutes 0 seconds.
Internal database snapshot has split point LSN = 00000026:0000089d:0001 and first LSN = 00000026:0000089c:0001.
This is an informational message only. No user action is required.

如果已使用修復選項，此訊息會顯示找到多少資料庫一致性錯誤，以及已修復多少錯誤。 此訊息也會寫入 Windows 應用程式事件記錄檔，作為 EventID=8957 的資訊層級訊息。 即使報告錯誤，此訊息也是資訊層級訊息。

訊息中以「內部資料庫快照集...」開頭的資訊只有在已在在線執行時，才會顯示 DBCC CHECKDB 資料庫不在模式中 SINGLE_USER 。 這是因為對於在線 DBCC CHECKDB而言，內部資料庫快照集是用來呈現一組一致的要檢查的數據。

本文不會討論如何針對所 DBCC CHECKDB 報告的每個特定錯誤進行疑難解答，而是報告錯誤時採用一般方法。 本文中的任何參考 CHECKDB 也適用於 DBCC CHECKTABLE 和 DBCC CHECKFILEGROUP ，除非另有說明。

原因

此命令 DBCC CHECKDB 會檢查資料庫頁面、數據列、配置頁面、索引關聯性、系統數據表引用完整性和其他結構檢查的實體和邏輯一致性。 如果其中任何一項檢查失敗（視您所選擇的選項而定），則會報告錯誤。

這些問題的原因可能來自文件系統損毀、基礎硬體系統問題、驅動程式問題、記憶體或記憶體快取中損毀的頁面，或 SQL Server 的問題。 如需如何識別報告錯誤根本原因的資訊，請參閱 調查根本原因。

解決方法

1. 在繼續還原備份或修復資料庫之前，請先解決系統上的任何基礎硬體相關問題。 套用與 I/O 路徑相關的任何裝置驅動程式、韌體、BIOS 和作業系統更新。 請與完整 I/O 路徑的系統管理員合作（本機計算機、設備驅動器、記憶體 NIC、SAN、後端記憶體和快取），以隔離並解決任何問題。 範例包括更新設備驅動器和檢查整個 I/O 路徑的設定。 如需檢查根本原因的詳細資訊，請參閱 調查根本原因。

2. 如果 DBCC CHECKDB 報告永久一致性錯誤，最好的解決方案就是從已知的良好備份還原數據。 如需詳細資訊，請參閱 還原和復原。

3. 套用最新的 SQL Server 累積更新或 Service Pack，以確定您未發生任何已知問題。 檢查 累積更新或 Service Pack 檔 ，找出任何與資料庫損毀相關的已知問題（一致性錯誤），並套用任何相關的修正程式。 如果 SQL Server 2022、2019、2017 的詳細修正清單，您可以在其中搜尋特定版本的所有修正。

4. DBCC CHECKDB如果錯誤間歇性，也就是說，如果錯誤出現在一次執行中，並在下一個執行時消失，您可能會遇到磁碟快取問題（裝置驅動程式或其他 I/O 路徑問題）。 請與 I/O 路徑的維護人員合作，找出並解決任何問題。 範例包括更新設備驅動器、檢查整個 I/O 路徑的設定，以及更新 I/O 路徑裝置和系統上的韌體和 BIOS。

5. 如果無法從備份還原， CHECKDB 則具有修復您可以使用的錯誤的功能。 修復層級有兩種：

   • REPAIR_REBUILD - 執行沒有任何數據遺失可能性的修復。
   • REPAIR_ALLOW_DATA_LOSS - 執行可能遺失數據之修復。

   如需詳細資訊，請參閱 DBCC CHECKDB 檔。

   當您選擇修復允許數據遺失時，請務必小心，因為它可能會讓您的資料庫處於邏輯不一致的狀態。 輸出 DBCC CHECKDB 會建議使用的最低修復層級。 執行多次是常見的作法CHECKDBREPAIR_ALLOW_DATA_LOSS，直到沒有回報更多錯誤為止。 這是因為修復修正了一組錯誤時，可能會發現其他中斷連結。 不過，如果根本原因尚未解決，可能會顯示新的錯誤。 因此，如果硬體或文件系統等系統層級問題造成數據損毀，則必須先解決這些問題，才能還原備份或修復。 Microsoft支援工程師無法在修復未修正一致性錯誤或資料庫備份損毀時協助實體復原損毀的數據。

   當您執行 DBCC CHECKDB時，會提供建議，指出修復所有錯誤所需的最小修復選項。 這些訊息類似下列輸出：

   CHECKDB 在資料庫 'mydb' 中發現了 0 個配置錯誤和 15 個一致性錯誤。
   REPAIR_ALLOW_DATA_LOSS 是 （mydb） 所找到 DBCC CHECKDB 錯誤的最低修復層級。

   修復建議是嘗試解決 所有 CHECKDB錯誤的最低修復層級。 最小修復層級並不表示此修復選項會修正所有錯誤。 某些錯誤根本無法修正。 此外，您可能需要多次執行修復程式。 並非所有回報的錯誤都需要使用此修復層級才能解決。 這表示並非所有修復 CHECKDB 都會 REPAIR_ALLOW_DATA_LOSS 造成數據遺失。 必須執行修復，以判斷解決錯誤是否會導致數據遺失。 協助縮小每個數據表修復層級的一種技術，是用於 DBCC CHECKTABLE 報告錯誤的任何數據表。 這會顯示指定數據表的最小修復層級。

   警告

   修復或數據匯出或匯入完成之後 CHECKDB ，您必須執行手動數據驗證。 如需詳細資訊，請參閱 DBCC CHECKDB 自變數。 修復之後，數據在邏輯上可能不一致。 例如，修復 （特別是 REPAIR_ALLOW_DATA_LOSS 選項） 可能會移除包含不一致數據的整個數據頁面。 在這種情況下，與另一個數據表具有外鍵關聯性的數據表，最後可能會有父數據表中沒有對應主鍵數據列的數據列。

6. 嘗試 編寫資料庫架構的腳本。 使用腳本來建立新的資料庫，然後使用BCP或SSIS匯出/匯入精靈之類的工具，盡可能將數據從損毀的資料庫匯出到新的資料庫。 從損毀的數據表匯出數據可能會失敗。 在這種情況下，請略過此數據表，移至下一個數據表，然後儲存您可以儲存的專案。

7. 請檢閱下列文章，以取得所產生的 DBCC CHECKDB 特定錯誤，並遵循提供的步驟（如果有的話）。 以下列出一些範例：

   • 錯誤 605 （MSSQLSERVER_605）
   • 錯誤 823 （MSSQLSERVER_823）
   • 錯誤 824 （MSSQLSERVER_824）
   • 錯誤 825 （MSSQLSERVER_825）
   • 錯誤 2508 （MSSQLSERVER_2508）
   • 錯誤 2511 （MSSQLSERVER_2511）
   • 錯誤 2512 （MSSQLSERVER_2512）
   • 錯誤 7987 （MSSQLSERVER_7987）
   • 錯誤 7988 （MSSQLSERVER_7988）
   • 錯誤 7995 （MSSQLSERVER_7995）
   • 錯誤 8993 （MSSQLSERVER_8993）
   • 錯誤 8994 （MSSQLSERVER_8994）
   • 錯誤 8996 （MSSQLSERVER_8996）

調查資料庫一致性錯誤的根本原因

若要識別資料庫一致性錯誤的根本原因，請考慮下列方法：

• 檢查 Windows 系統事件記錄檔中是否有任何系統層級、驅動程式或磁碟相關錯誤，並與您的硬體製造商合作來解決這些錯誤。
• 針對計算機和/或磁碟系統，執行硬體製造商所提供的任何診斷。
• 請與您的硬體廠商或裝置製造商合作，以確定：
  • 硬體裝置和設定會確認 Microsoft SQL Server 資料庫引擎 輸入/輸出需求。
  • I/O 路徑中所有裝置的裝置驅動程式和其他支援軟體元件都已更新。
• 請考慮在報告一致性錯誤所在之資料庫的磁碟驅動器上使用 SQLIOSim 之類的公用程式。 SQLIOSim 是與 SQL Server 引擎無關的工具，可測試磁碟系統 I/O 的完整性。 SQLIOSim 隨附於 SQL Server，不需要個別下載。 您可以在 \MSSQL\Binn 資料夾中找到。
• 檢查 累積更新或 Service Pack 檔 ，找出任何與資料庫損毀相關的已知問題（一致性錯誤），並套用任何相關的修正程式。 如果 SQL Server 2022、2019、2017 的詳細修正清單，您可以在其中搜尋特定版本的所有修正。
• 檢查 SQL Server 所報告的任何其他錯誤，例如存取違規或判斷提示。 針對損毀資料庫的活動經常會導致存取違規例外狀況或判斷提示錯誤。
• 請確定您的資料庫正在使用 PAGE_VERIFY CHECKSUM 選項。 如果報告總和檢查碼錯誤，這表示 SQL Server 將頁面寫入磁碟之後發生一致性錯誤。 因此，您應該徹底檢查您的 I/O 子系統。 如需總和檢查碼錯誤的詳細資訊，請參閱 如何針對 SQL Server 中的 Msg 824 進行疑難解答。
• 在 ERRORLOG 中尋找訊息 832 錯誤。 這些錯誤可能表示頁面在寫入磁碟之前在快取中時可能會損毀。 如需詳細資訊，請參閱 如何在 SQL Server 中針對 Msg 832 進行疑難解答。
• 在另一個系統上，嘗試還原資料庫備份，您知道該備份為「乾淨」（沒有來自 CHECKDB的錯誤），後面接著跨越錯誤產生時間的事務歷史記錄備份。 如果您可以藉由還原「全新」資料庫備份和事務歷史記錄備份來「重新建立」此問題，請連絡 Microsoft技術支援以尋求協助。
• 數據純潔性錯誤可能是應用程式在 SQL Server 數據表中插入或更新無效數據時發生問題。 如需針對數據純潔性錯誤進行疑難解答的詳細資訊，請參閱 針對 SQL Server 2005 中的 DBCC 錯誤 2570 進行疑難解答。
• 使用 chkdsk 命令檢查文件系統的完整性。 SQL Server 執行時請勿chkdsk執行。 如果 SQL Server 正在寫入正在檢查的檔案，可能會報告暫時性檔案錯誤。 此外，例如 或 /f 之類的/r參數可以將檔案位元組移至磁碟上的不同位置，如果 SQL Server 也寫入或讀取這些檔案，這類移動可能會導致損毀。 因此，在執行 命令之前 chkdsk ，請務必停止 SQL Server。 此外，請小心修復選項，例如 /r 和 /f。 在執行修復之前，請確定您有資料庫的備份，因為這些選項可能會損毀檔案，如果 找到磁碟錯誤。chkdsk

其他相關資訊

如需如何執行命令之 DBCC CHECKDB 語法和資訊或選項的詳細資訊，請參閱 DBCC CHECKDB （Transact-SQL） 。

如果使用 找到 CHECKDB任何錯誤，則會在 ERRORLOG 中報告類似下列訊息的其他訊息，以便報告錯誤：

**Dump thread - spid = 0, EC = 0x00000000855F5EB0
***Stack Dump being sent toFilePath\FileName
* ******************************************************************************
*
* BEGIN STACK DUMP:
*  Date/Timespid 53
*
* DBCC database corruption
*
* Input Buffer 84 bytes -
*             dbcc checkdb(mydb)
*
* *******************************************************************************
*   -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000001E8
External dump process return code 0x20002001.

錯誤資訊已提交至 Watson 錯誤報告。

用於錯誤報告的檔案包括 SQLDump<nnn>.txt 檔案。 此檔案對於歷程記錄用途很有用，因為它包含 XML 格式中 CHECKDB 找到的錯誤清單。

若要找出上次執行的時間 DBCC CHECKDB ，而未偵測到資料庫的錯誤（上次已知清除 CHECKDB），請檢查 SQL Server ERRORLOG。 尋找類似下列訊息的用戶或系統資料庫。 此訊息會以事件識別碼 = 17573 在 Windows 應用程式事件記錄檔中寫入資訊層級訊息：

資料庫 'master' 的日期/時間 spid7s CHECKDB 在 Date/Time22：11：11：11.417 上完成（當地時間）。 這隻是參考訊息;不需要用戶動作