症狀

執行 DBCC CHECKDB (或其他類似的命令,像 CHECKTABLE) 時,會如下所示的訊息寫入 SQL Server 錯誤記錄檔中: 

日期/時間spid53      DBCC CHECKDB (mydb) 由發現 15 錯誤的 MYDOMAIN\theuser 執行,而且已修復 0 個錯誤。 已耗用時間: 0 小時 0 分 0 秒。  內部資料庫快照集已分割點 LSN = 00000026:0000089 d: 0001 和名字的 LSN = 00000026:0000089 c: 0001。  這是參考用訊息。 使用者不不需要任何動作。

此訊息會顯示找到多少資料庫一致性錯誤和多少已修復 (如果使用修復選項] 指令)。 此訊息也會寫入到 Windows 應用程式事件日誌 」 中作為資訊層級郵件與識別碼 = 8957 (即使要報告錯誤,此訊息是資訊層級的訊息)。

開頭為 「 內部資料庫快照集...」 訊息中的資訊,才會出現連線,也就是如果資料庫不在 SINGLE_USER 模式下執行 DBCC CHECKDB。 這是因為線上的 DBCC CHECKDB,為內部的資料庫快照集可用來顯示一組一致性檢查的資料。

本文將討論如何疑難排解每個特定的錯誤報告的 DBCC CHECKDB 但而是一般的方法中,如果有報告錯誤。 除非特別聲明,否則本文中的任何參考 CHECKDB 也適在於和 CHECKFILEGROUP。

原因

DBCC CHECKDB 會檢查資料庫分頁、 資料列、 配置分頁、 索引關聯性、 系統資料表參考完整性和其他結構檢查的實體與邏輯一致性。 如果其中有任何檢查失敗 (視您所選擇的選項),則會報告錯誤,作為命令的一部分。

這些問題的原因而異檔案系統損毀,基礎系統的硬體問題,驅動程式問題時,記憶體或與 SQL Server 引擎的問題中的損毀的頁。 閱讀 [解析度] 區段,如需有關如何找出所報告的錯誤的原因。

解決方案

首先,最佳的解決方案如果 DBCC CHECKDB 報告一致性錯誤是從已知完好的備份還原。 不過,如果您無法從備份還原,然後 CHECKDB 就會提供可修復錯誤的功能。 如果系統層級的問題,例如檔案系統或硬體可能會造成這些問題,則建議您更正還原,或執行修復之前先將這些資料。

當您執行 DBCC CHECKDB 建議可指出哪些才能修復所有的錯誤的最小的修復選項。 這些訊息看起來可能如下所示:

CHECKDB 會位於資料庫 'mydb' 0 的配置錯誤和 15 的一致性錯誤。 repair_allow_data_loss是 DBCC CHECKDB (mydb 所發現的錯誤的最小的修復層級

修復建議最低層級的 [修復] 來嘗試解決來自 CHECKDB 的所有錯誤。 這不表示此修復選項會實際修正所有錯誤。 此外,並非所有的錯誤報告可能會需要此層次的 [修復] 來解決這種錯誤。 這表示並非所有的錯誤報告 CHECKDB 時 repair_allow_data_loss 建議您將會導致資料遺失。 若要判斷的解析度,以錯誤會導致資料遺失,必須執行修復。 有助於縮小的修復層級將會為每個資料表的其中一項技巧是在於用於報告錯誤的任何資料表。 如此將會顯示哪些最低層級的給定的資料表的修復。

若要找出為何發生資料庫一致性錯誤的原因,請考慮這些方法:

  • 檢查 Windows 系統事件日誌中的任何系統層級、 驅動程式或磁碟相關錯誤

  • 檢查使用chkdsk 命令檔案系統的完整性。

  • 執行任何電腦和 (或) 磁碟系統您的硬體製造商提供的診斷。

  • 使用您的硬體廠商或裝置製造商,以確保:

    • 硬體裝置及設定確認SQL Server 的 I/O 需求

    • 更新的裝置驅動程式和其他支援的軟體元件的 I/O 路徑中的所有裝置

  • 請考慮使用像是SQLIOSim公用程式,在尚一致性錯誤的資料庫的相同磁碟機上。 SQLIOSim 是一個獨立的測試的 I/O 磁碟系統的完整性,SQL Server 引擎的工具。 請注意 SQLIOSim 附有 SQL Server 2008年,並且不需要個別的下載。

  • 請檢查有任何其他 SQL Server,例如存取違規或判斷提示所報告的錯誤。

  • 請確定您的資料庫使用的 PAGE_VERIFY 總和檢查碼的選項。 如果有正在報告的總和檢查碼錯誤,這些都是 SQL Server 已寫入之後發生錯誤的一致性頁面到磁碟,因此應該徹底檢查磁碟系統的指標。 總和檢查碼錯誤的相關資訊,請參閱如何疑難排解在 SQL Server 中的訊息 824

  • 尋找訊息 832 在錯誤記錄檔中的錯誤。 這些是一種網頁月的指標之前的快取中時,損毀寫入磁碟。 如需詳細資訊,請參閱如何疑難排解在 SQL Server 中的訊息 832

  • 嘗試還原資料庫備份,您也就是知道 「 清理 」 (沒有來自 CHECKDB 的錯誤),而您知道的交易記錄檔備份橫跨在遇到這個錯誤時的時間。 如果您可以 「 重新執行 」 問題,可以還原 「 乾淨 」 的資料庫備份與交易記錄檔,然後連絡 Microsoft 技術支援部門以取得協助。

  • 資料單純性錯誤可插入或更新成 SQL Server 資料表的資料不正確的應用程式有問題。 如需有關疑難排解資料單純性錯誤請參閱下列文件:在 SQL server 2005 中疑難排解 DBCC 錯誤 2570年

其他相關資訊

DBCC CHECKDB 及有關如何執行命令的資訊/選項語法的詳細資訊,請參閱 SQL Server 線上叢書 》 的主題DBCC CHECKDB 命令上。

如果由 CHECKDB 找不到任何錯誤,如下所示的其他訊息中會報告錯誤記錄檔的錯誤報告目的:

日期/時間spid53 使用 'dbghelp.dll' '4.0.5' 版 日期/時間spid53 * * 傾印執行緒: spid = 0,EC = 0x00000000855F5EB0 日期/時間spid53 * * * 堆疊傾印傳送至FilePath\FileName日期/時間spid53 * * * * 日期/時間spid53 * 日期/時間spid53 * 開始堆疊傾印: 日期/時間spid53 *日期/時間spid 53 日期/時間spid53 * 日期/時間spid53 * DBCC 資料庫損毀 日期/時間spid53 * 日期/時間spid53 * 輸入緩衝區 84 位元組- 日期/時間spid53 * dbcc checkdb(mydb) 日期/時間spid53 *日期/時間spid53 * * * * 日期/時間spid53 *--- 日期/時間spid53 * 短堆疊傾印 傾印的日期/時間spid53 堆疊簽章是 0x00000000000001E8 日期/時間spid53 外部的傾印程序的傳回碼 0x20002001。 錯誤訊息已被提出至 Watson 錯誤報告。

錯誤報告所使用的檔案包含 SQLDump < nnn >.txt 檔案。 這個檔案可以是用於歷史的用途,因為它包含來自 CHECKDB 找到以 XML 格式錯誤的清單。

若要瞭解上次執行 DBCC CHECKDB 沒有資料庫 (最後一個已知乾淨 CHECKDB) 偵測到錯誤時,請檢查 SQL Server 錯誤記錄檔訊息類似下列的資料庫或系統資料庫 (此訊息會寫入資訊層級訊息在 Windows 應用程式事件記錄檔與識別碼 = 17573):

資料庫 '主要' 的日期/時間spid7s CHECKDB 完成不會出現在 [日期/時間22:11:11.417 (當地時間) 上的錯誤。 這是告知性訊息不不需要任何使用者動作

Need more help?

擴展您的技能

探索訓練 >

優先取得新功能

加入 MICROSOFT 測試人員 >

Was this information helpful?

How satisfied are you with the translation quality?
What affected your experience?

Thank you for your feedback!

×