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

本文說明如何針對 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 的資訊層級訊息。 即使已回報錯誤，此訊息也是資訊層級訊息。

訊息中以「internal database snapshot...」開頭的資訊，只有在 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、後端儲存體和快取）和記憶體（RAM），以隔離並解決任何問題。 範例包括更新設備驅動器，以及檢查整個 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 會針對最低修復層級提出建議。 以REPAIR_ALLOW_DATA_LOSS執行CHECKDB多次直到不再回報錯誤，是常見的作法。 這是因為，當修復作業修正了一組錯誤時，可能會發現其他損壞的關聯。 不過，如果根本原因尚未解決，可能會顯示新的錯誤。 因此，如果硬體或文件系統等系統層級問題造成數據損毀，則必須先解決這些問題，才能還原備份或修復。 Microsoft支援工程師無法協助實體復原損毀的數據，如果修復無法修正一致性錯誤，或如果資料庫備份已損毀。

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

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

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

    警告

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

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

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

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

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

  • 檢查 Windows 系統事件記錄檔中是否有任何系統層級、驅動程式或磁碟相關錯誤，並與您的硬體製造商合作來解決這些錯誤。
  • 針對電腦和/或磁碟系統，執行硬體製造商所提供的任何診斷。 大部分的系統都提供存儲設備（硬碟）、記憶體、CPU、系統主機板、RAID 陣列和多個元件的 BIOS/UEFI 內建診斷。
  • 請與您的硬體廠商或裝置製造商合作，以確定：
  • 請考慮在含有回報一致性錯誤之資料庫的磁碟機上使用 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 正在寫入正在檢查的檔案，可能會報告暫時性檔案錯誤。 此外，例如 /r 或 /f 之類的參數可以將檔案位元組移至磁碟上的不同位置，如果 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' 的 Date/Time spid7s CHECKDB 已於 Date/Time22:11:11.417（當地時間）完成，且沒有錯誤。 這隻是參考訊息;不需要用戶動作

  • Last updated on