您目前已離線,請等候您的網際網路重新連線

不支援您的瀏覽器

您必須更新瀏覽器,才能使用此網站。

更新至最新版本的 Internet Explorer

如何疑難排解 DBCC CHECKB 所報告的資料庫一致性錯誤

Extended support for SQL Server 2005 ends on April 12, 2016

If you are still running SQL Server 2005 after April 12, 2016, you will no longer receive security updates and technical support. We recommend upgrading to SQL Server 2014 and Azure SQL Database to achieve breakthrough performance, maintain security and compliance, and optimize your data platform infrastructure. Learn more about the options for upgrading from SQL Server 2005 to a supported version here.

請注意--重要:本文是以 Microsoft 機器翻譯軟體翻譯而成,且可能由 Microsoft Community 利用 Community Translation Framework技術或人工進行事後編修。翻譯過程並無專業譯者參與。Microsoft 同時提供使用者人為翻譯、機器翻譯及社群編修後的機器翻譯三種版本的文章,讓使用者可以依其使用語言使用知識庫中的所有文章。但是,所有翻譯文章都可能不盡完美,內容都可能出現詞彙、語意或文法上的錯誤。就翻譯內容之不正確或錯誤,或客戶因使用翻譯內容所產生的任何損害,微軟不負擔任何責任。Microsoft將依合理的商業努力不斷地更新機器翻譯軟體和工具,以期能為使用者提供更好的服務。

按一下這裡查看此文章的英文版本:2015748
徵狀

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

2010-03-31 22:07:06.34 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 是一個獨立的 SQL Server 引擎,若要測試磁碟系統 I/O 完整性的工具。請注意 SQLIOSim 附有 SQL Server 2008年,並且不會不 reuiqre 個別的下載。
  • 請檢查有任何 SQL Server,例如存取違規所報告的錯誤。這些類型的問題可能會導致資料庫損毀因此務必要先解決這些錯誤。
  • 請確定您的資料庫使用的 PAGE_VERIFY 總和檢查碼的選項。如果有正在報告的總和檢查碼錯誤,這些都是 SQL Server 已寫入之後發生錯誤的一致性頁面到磁碟,因此應該徹底檢查磁碟系統的指標。總和檢查碼錯誤的相關資訊,請參閱如何疑難排解在 SQL Server 中的訊息 824
  • 尋找訊息 832 中的錯誤錯誤記錄檔。這些是指標的網頁可能已經損毀時仍在快取之前寫入磁碟。如需詳細資訊,請參閱如何疑難排解在 SQL Server 中的訊息 832
  • 請試著還原資料庫備份,您也就是知道 「 清除 」 (來自 CHECKDB 沒有錯誤),以及您知道的交易記錄檔備份跨越遇到這個錯誤時的時間。如果您可以 「 重新執行 」 這個問題,可以還原 「 乾淨 」 的資料庫備份與交易記錄檔,然後連絡 Microsoft 技術支援部門以取得協助。
  • 資料單純性錯誤可以被插入或更新到 SQL Server 資料表的資料不正確的應用程式有問題。如需有關疑難排解資料單純性錯誤請參閱下列文件:在 SQL server 2005 中疑難排解 DBCC 錯誤 2570年
其他相關資訊

如需詳細資訊的 DBCC CHECKDB 和資訊/選項有關如何執行命令的語法,讀取DBCC CHECKDB 命令上 SQL Server 線上叢書 》 的主題。

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

2010-03-31 22:07:06.34 spid53 使用 'dbghelp.dll' '4.0.5' 版
2010-03-31 22:07:06.35 spid53 * * 傾印執行緒: spid = 0,EC = 0x00000000855F5EB0
2010-03-31 22:07:06.35 spid53 * * * 堆疊傾印傳送至 C:\Program 必要 SQL Server\MSSQL10。SQL2008\MSSQL\LOG\SQLDump0012.txt
2010-03-31 22:07:06.35 spid53      * *******************************************************************************
2010-03-31 22:07:06.35 spid53 *
2010-03-31 22:07:06.35 spid53 * 開始堆疊傾印:
2010-03-31 22:07:06.35 spid53 * 03/31/10 22:07:06 spid 53
2010-03-31 22:07:06.35 spid53 *
2010-03-31 22:07:06.35 spid53 * DBCC 資料庫損毀
2010-03-31 22:07:06.35 spid53 *
2010-03-31 22:07:06.35 spid53 * 輸入緩衝區 84 位元組-
2010-03-31 22:07:06.35 spid53 * dbcc checkdb(mydb)
2010-03-31 22:07:06.35 spid53 *
2010-03-31 22:07:06.35 spid53      * *******************************************************************************
2010-03-31 22:07:06.35 spid53      * -------------------------------------------------------------------------------
2010-03-31 22:07:06.35 spid53 * 短堆疊傾印
2010-03-31 22:07:06.38 spid53 堆疊傾印簽章是 0x00000000000001E8
2010-03-31 22:07:07.42 spid53 外部的傾印程序的傳回碼 0x20002001。
錯誤訊息已被提出至 Watson 錯誤報告。

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

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

2010-04-01 10:13:59.80 spid7s CHECKDB 資料庫 '主要' 完成不會出現在 2010年-03-31 22:11:11.417 (當地時間) 上的錯誤。這是告知性訊息 ;不不需要任何使用者動作

注意 :本文屬於「快速發佈」文章,係由 Microsoft 技術支援或組織內部直接建立。 本文所包含的資訊是為了回應新問題而依現況提供。 因此為了迅速對外發佈,文章內容可能含有印刷錯誤,而且可能會在不另行通知的情況下進行修改。 如需其他考量事項,請參閱使用規定

Warning: This article has been translated automatically

內容

文章識別碼:2015748 - 最後檢閱時間:05/07/2014 07:20:00 - 修訂: 1.0

  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Express with Advanced Services
  • Microsoft SQL Server 2008 R2 Developer
  • Microsoft SQL Server 2008 R2 Enterprise
  • Microsoft SQL Server 2008 R2 Standard
  • Microsoft SQL Server 2008 R2 Web
  • Microsoft SQL Server 2008 R2 Workgroup
  • Microsoft SQL Server 2012 Developer
  • Microsoft SQL Server 2012 Enterprise
  • Microsoft SQL Server 2012 Express
  • Microsoft SQL Server 2012 Standard
  • Microsoft SQL Server 2012 Web
  • Microsoft SQL Server 2014 Developer
  • Microsoft SQL Server 2014 Enterprise
  • Microsoft SQL Server 2014 Express
  • Microsoft SQL Server 2014 Standard
  • Microsoft SQL Server 2014 Web
  • kbmt KB2015748 KbMtzh
意見反應