疑難排解在 SQL Server 2005 及更新版本的 DBCC 錯誤 2570

文章翻譯 文章翻譯
文章編號: 923247 - 檢視此文章適用的產品。
全部展開 | 全部摺疊

在此頁中

簡介

本文將告訴您 SQL Server 的錯誤為 2570,造成的原因為何錯誤,以及如何解決問題。

其他相關資訊

DATA_PURITY 檢查

在 SQL Server 2005,新的選項: DATA_PURITY,已經新增到不一致和在於命令。當您執行 DBCC CHECKDB指令會執行的在於使用指令啟用此選項,或在資料表的所有資料列的每一個資料行值 」 資料單純性"驗證或在資料庫中的資料表。為了確保不會執行這些新的檢查儲存於資料行的值是否有效 (也就是,這些值不會跨範圍與該資料行的資料型別相關聯的網域)。[執行驗證的本質,取決於資料行的資料型別。[遵循非詳細列出提供一些範例:
摺疊此表格展開此表格
資料行資料型別執行資料驗證的型別
Unicode 字元資料長度應為2 的倍數。
日期時間[天] 欄位應該介於 1753 年 1 月 1年 12 月 31 和 9999。「 時間 」 欄位必須是早於 '11:59:59:999 PM。
實際測量及抹檢查有不正確浮點值會喜歡 SNAN、 QNAN、 NINF,ND、 PD、 PINF。
並非所有的資料型別會檢查有資料行的有效性資料。只是可以讓預存的值,已用完正在檢查範圍。比方說, tinyint 資料型別有一個 0 到 255 之間的有效範圍,而且儲存在單一位元組 (這只能儲存從 0 到 255 之間的值),所以檢查值不需要。

資料的單純性驗證檢查都被停用自動替所有的資料庫。取決於幾個啟用檢查因素:
  • 對於 SQL Server 2005 及更新版本中所建立的資料庫,這些檢查項目會預設成啟用狀態,無法停用,因此使用 DATA_PURITY 選項,執行 DBCC CHECKDB 或在於命令時並不相關。
  • 對於較早版本的 SQL 中所建立的資料庫伺服器上,例如 SQL Server 2000年、 SQL Server 7.0,以及升級為 SQL 的版本預設不啟用 server 2005 中,這些檢查項目。為了讓這些檢查項目若要執行,您必須指定 [DATA_PURITY] 選項在 DBCC CHECKDB 或在於命令。這可能會導致兩件事:
    • DBCC 命令完成,並報告資料庫很乾淨,包括所有資料的單純性檢查。這項事實記錄中資料庫標頭。所有後續的 DBCC CHECKDB 或在於指令執行次數將會注意到這項資訊,而會自動執行資料檢查單純性,如會發生如 SQL Server 2005 中建立的資料庫。在也就是說,一旦資料庫被知道是 「 乾淨 」 資料的單純性檢查是自動執行。
    • DBCC 命令完成,但會報告有關的問題資料不一致。如果是這種情況下,您則必須清除資料庫移除不一致之處,然後再次執行 DBCC 命令。您必須指定 [DATA_PURITY] 選項,直到 DBCC 命令資料庫會回報給是乾淨的。
  • 如果指定 [PHYSICAL_ONLY] 選項,則當 DBCC執行 CHECKDB 或在於命令、 資料的單純性檢查執行。

徵狀

無效或超出範圍的資料可能已儲存在 SQL伺服器資料庫中較早的版本,原因如下:
  • 無效的資料已在使用大量時出現在原始檔插入方法,例如 bcp 公用程式。
  • 無效的資料已通過的 RPC 事件呼叫SQL Server。
  • 其他可能的原因保留的實體資料損毀的資料行中的值不正確的狀態。
如果您在資料表的資料行中有無效的資料,可能會遇到問題的操作,會針對無效的資料型別而定。不過,也很可能不會造成問題,就會出現,而您在 SQL Server 2005 及更新版本上執行 DBCC CHECKDB 或在於命令之前,並不會發現無效的資料。

這些徵狀的一些您可能會注意到不正確的資料是否存在受限於包括 (但並不會限制至):
  • 存取違規或其他類型的例外狀況時執行針對受影響的資料行的查詢。
  • 對執行查詢所傳回的結果不正確受影響的資料行。
  • 錯誤或問題時,會針對正在建立統計資料受影響的資料行。
  • 如下所示的錯誤訊息:
    訊息9100,層級 23 狀態 2,行 1 可能偵測到的索引損毀。復原失敗CHECKDB。

DATA_PURITY 問題報告

當您執行 DBCC CHECKDB 在於使用或指令啟用 [DATA_PURITY] 選項 (或執行資料的單純性檢查[自動]),而且由 DBCC 檢查資料表中都會有無效的資料指令,DBCC 輸出包含額外的訊息,指出資料有問題。有些範例錯誤訊息,指出資料單純性問題如下所示:
DBCC 結果"account_history"。
訊息 2570年,層次 16,狀態 1,行 1
一頁 (1:1073),物件 ID 1977058079,索引識別碼為 0,磁碟分割編號 129568478265344 中插槽 33配置單位識別碼 129568478265344 (型別 「 同資料列資料 」)。"Account_name_japan"的資料行值超出範圍的資料型別"nvarchar"。更新資料行為合法值。
訊息 2570年,層次 16,狀態 1,行 1
網頁 (1:1156),物件中的介面槽 120識別碼 1977058079、 索引識別碼為 0,磁碟分割識別碼 129568478265344,配置單位識別碼129568478265344 (輸入"同資料列的資料 」)。"Account_name_japan"的資料行值會出資料型別"nvarchar"的範圍。更新資料行為合法值。
有是 153137 物件"account_history"的 1080年頁面中的資料列。
找到 CHECKDB0 的配置錯誤和"account_history"資料表中的 338 一致性錯誤(物件 ID 1977058079)。
CHECKDB 找出 0 配置錯誤和 338'BadUnicodeData' 的資料庫一致性錯誤。
DBCC 執行完畢。如果 DBCC 印出錯誤訊息,請連絡您的系統管理員。
'Table1' DBCC 結果。
訊息 2570,層級16,狀態 3,第 1 行
網頁 (1:154)、 介面槽物件 ID 2073058421 中的 0,索引識別碼0,磁碟分割識別碼 72057594038321152,配置單位識別碼 72057594042318848 (型別「 同資料列資料 」)。"欄 2 中"的資料行值超出範圍,如 「 真正 」 的資料型別。更新資料行為合法值。
物件的雙頁中有 4 個資料列"table1"。
CHECKDB 找出 0 配置錯誤和 1 的一致性的錯誤資料表 'table1' (物件 ID 2073058421)。
CHECKDB 找到 0 配置錯誤以及在資料庫 'realdata' 1 一致性錯誤。DBCC 執行完畢。如果DBCC 印出錯誤訊息,請連絡您的系統管理員。
DBCC 'table2' 的結果。
訊息 2570,層級16,狀態 3,第 1 行
網頁 (1:155)、 介面槽物件 ID 2105058535 中的 0,索引識別碼0,磁碟分割識別碼 72057594038452224,配置單位識別碼 72057594042449920 (型別「 同資料列資料 」)。"欄 2 中"的資料行值超出範圍,如 「 十進位 」 的資料型別。更新資料行為合法值。
1 物件的頁面中有 4 個資料列"table2"。
CHECKDB 找出 0 配置錯誤和 1 的一致性的錯誤資料表 'table2' (物件 ID 2105058535)。
CHECKDB 找到 0 配置錯誤以及在資料庫 'realdata' 1 一致性錯誤。DBCC 執行完畢。如果DBCC 印出錯誤訊息,請連絡您的系統管理員。
'表單' DBCC 結果。
訊息 2570,層級16,狀態 3,第 1 行
網頁 (1:157)、 介面槽物件 ID 2121058592 中的 0,索引識別碼0,磁碟分割識別碼 72057594038517760,配置單位識別碼 72057594042515456 (型別「 同資料列資料 」)。"欄 2 中"的資料行值超出範圍 」 的日期時間 」 的資料型別。更新資料行為合法值。
1 物件的頁面中有 3 的資料列「 表單 」。
CHECKDB 找出 0 配置錯誤和 1 的一致性的錯誤資料表 '表單' (物件 ID 2121058592)。
CHECKDB 找到 0 配置錯誤以及在資料庫 'realdata' 1 一致性錯誤。DBCC 執行完畢。如果DBCC 印出錯誤訊息,請連絡您的系統管理員。
針對就會產生包含無效的資料行的值,「 2570年 」 錯誤的每一資料列。

修復資料的單純性問題

使用任何的 DBCC 修復無法修復的 2570年 」 錯誤選項。這是因為它是不可能判斷何種值的 DBCC應該用來取代無效的資料行的值。因此,資料行的值必須與以手動方式更新。

若要執行手動更新,您必須尋找資料列可在發生問題。有兩種方式可以完成這項作業。
  • 對包含的資料表執行查詢若要尋找包含無效的值的資料列的值不正確。
  • 使用來自 2570年錯誤的資訊來識別包含無效的值的資料列。
我們將討論這兩種方法,詳細說明使用若要尋找具有無效的資料之資料列的範例。

一旦您找到正確的資料列,必須建立新的值會用來決定取代現有的資料無效。這個決定也設成可非常仔細地根據應用程式運作的值的範圍,以及什麼合理邏輯該資料列的資料。您必須選擇如下:
  • 如果您知道它應該是什麼值,將它設定為,特定的值。
  • 請將它設定為可接受的預設值。
  • 設為 NULL 的資料行的值。
  • 將資料行的值設定為最大值或最小值這個資料型別的資料行。
  • 如果您覺得特定的資料列不屬於任何不需要使用有效的資料行值,您可以刪除該資料列完全。

尋找與使用 T SQL 查詢的值不正確的資料列

您必須一直執行到尋找資料列的查詢類型無效的值取決於 [報告問題的資料行的資料型別。如果您看一下 2570年錯誤訊息,您會注意到二個重要的項目將協助您進行這樣的資訊。在下列範例中,資料行"account_name_japan"的值超出範圍的資料型別"nvarchar"。沒問題很容易地識別有問題,以及資料型別資料行所包含的資料行。因此,我們一次您知道的資料型別也牽涉到的資料行,您可以制定查詢來尋找包含無效的值的資料列資料行中,選取所需來識別該資料列 (如在述詞的資料行WHERE 子句) 的任何進一步更新或刪除。

Unicode 資料型別:
SELECT col1 ,DATALENGTH(account_name_japan) as Length ,account_name_japan 
FROM account_history
WHERE DATALENGTH(account_name_japan) % 2 != 0

浮點數資料型別:
-- Change col1 to your actual primary key column(s), col2 to the column from the 2570 error, table1 to the table from the CHECKDB output

SELECT col1, col2 FROM table1
WHERE col2<>0.0 AND (col2 < 2.23E-308 OR col2 > 1.79E+308) AND (col2 < -1.79E+308 OR col2 > -2.23E-308)

實際的資料型別:
-- Change col1 to your actual primary key column(s), col2 to the column from the 2570 error, table1 to the table from -- the CHECKDB output

SELECT col1, col2 FROM testReal 
WHERE col2<>0.0 AND (col2 < CONVERT(real,1.18E-38) OR col2 > CONVERT(real,3.40E+38)) AND (col2 < CONVERT(real,-3.40E+38) OR col2 > CONVERT(real,-1.18E-38)) 
ORDER BY col1; -- checks for real out of range
小數和數字資料型別:
SELECT col1 FROM table2
WHERE col2 > 9999999999.99999 
OR col1 < -9999999999.99999
請記住,您必須調整為基礎的值整數位數和小數位數與您所定義的小數或數字資料行。在上述範例中,資料行定義為第 2 欄 decimal(15,5)。

日期時間資料型別:
您必須執行兩個不同的查詢,找出包含無效的值,日期時間資料行的資料列。
SELECT col1 FROM table3
WHERE col2 < '1/1/1753 12:00:00 AM' OR col2 > '12/31/9999 11:59:59 PM'

SELECT col1 FROM table3 WHERE
((DATEPART(ms,col2)+ (1000*DATEPART(s,col2)) + (1000*60*DATEPART(mi,col2)) + (1000*60*60*DATEPART(hh,col2)))/(1000*0.00333)) 
> 25919999

尋找與使用的實體位置的值不正確的資料列:

您可以使用這個方法,如果您找不到的資料列使用上文所述的 T SQL 方法感興趣。在 2570年錯誤訊息中,列印包含不正確的值之資料列的實體位置。針對範例中,看看下列訊息:
一頁 (1:157),物件 ID 2121058592,索引識別碼為 0,磁碟分割編號 72057594038517760 中插槽 0配置單位識別碼 72057594042515456 (型別 「 同資料列資料 」)。"欄 2 中"的資料行的值是超出範圍 」 的日期時間 」 的資料型別。若要修正的更新資料行值。
在這封郵件,您會注意到的資訊: 網頁 (1:157),位置 0。這是您需要識別資料列的資訊。FileId 是 1,PageInFile 是 157,而 Rid 是 0。一旦您有這項資訊,您需要執行的命令,如下所示:
DBCC TRACEON ( 3604 )
DBCC PAGE ( realdata , 1 , 157 , 3 )
這個命令將會列印整個網頁的內容。參數DBCC PAGE 命令為:
  • 資料庫名稱
  • FileId
  • PageInFile
  • 列印選項
當您執行這項指令時,您會注意到輸出,包含類似下列的格式資訊:
Slot 0 Offset 0x60 Length 19 Record Type = PRIMARY_RECORD Record
		  Attributes = NULL_BITMAP Memory Dump @0x44D1C060 00000000: 10001000 01000000
		  ffffffff ffffffff ?................ 00000010:
		  0200fc???????????????????????????????... Slot 0 Column 0 Offset 0x4 Length 4 col1 = 1Slot 0 Column 1 Offset 0x8 Length 8 col2 = Dec 31 1899 19:04PM Slot 1 Offset 0x73 Length 19 Record Type = PRIMARY_RECORD Record
		  Attributes = NULL_BITMAP Memory Dump @0x44D1C073 00000000: 10001000 02000000
		  0ba96301 f8970000 ?..........c..... 00000010:
		  0200fc???????????????????????????????... Slot 1 Column 0 Offset 0x4 Length 4
		  col1 = 2 Slot 1 Column 1 Offset 0x8 Length 8 col2 = Jul 8 2006 9:34PM Slot 2
		  Offset 0x86 Length 19 Record Type = PRIMARY_RECORD Record Attributes =
		  NULL_BITMAP Memory Dump @0x44D1C086 00000000: 10001000 03000000 0ba96301
		  f8970000 ?..........c..... 00000010: 0200fc???????????????????????????????...
		  Slot 2 Column 0 Offset 0x4 Length 4 col1 = 3 Slot 2 Column 1 Offset 0x8 Length
		  8 col2 = Jul 8 2006 9:34PM 
您可以在此輸出清楚地看到您有興趣的資料列的資料行值。如此一來,您必須儲存在頁面的插槽 0 的資料列。從錯誤訊息中,您知道該欄 2 中會有問題。因此,您可以採取的欄 1 的值介面槽 0,並將其作為您的 update 陳述式的 WHERE 子句中的述詞或者,刪除陳述式。

警告 我們建議您使用第一種方法 (也就是使用 T SQL查詢,以尋找所需的資訊)。使用 DBCC PAGE 命令列為最後的解決方法。採用具有特別小心,但是您在生產環境中使用這個命令環境。最好也能還原在測試上的實際執行資料庫伺服器上,然後以取得使用 DBCC PAGE,所有必要的資訊,然後執行在實際執行伺服器上的更新。如同以往一樣,請確定將備份保存在準備好如果有任何差錯,而且您需要還原成先前的副本資料庫。

?考

如需有關的 DBCC CHECKDB 陳述式的詳細資訊,請參閱下列的 Microsoft 開發人員 」 DBCC CHECKDB (考慮改用-SQL) 」 主題網路 (MSDN) 網站:
http://msdn2.microsoft.com/en-us/library/ms176064.aspx
如需有關已知問題在 SQL Server 2000 中,按一下下面的文件編號,檢視「 Microsoft 知識庫文件:
900335修正: SQL Server 2000年自動資料庫復原作業可能會失敗,如果索引會包含 FLOAT 資料型別或 REAL 資料型別,而此資料型別則包含與 NaN 值
如需有關 RPC 事件的詳細資訊,請參閱在下列 MSDN 網站上的"呼叫預存程序 (OLE DB) 」 主題:
http://msdn2.microsoft.com/en-us/library/aa198358 (SQL.80).aspx
如需不同資料型別的詳細資訊,請參閱在下列 MSDN 網站上的"呼叫預存程序 (OLE DB) 」 主題:
http://msdn2.microsoft.com/en-us/library/ms187752.aspx
如需有關浮動的點值慣例的詳細資訊,請造訪下列 Intel 網站:
http://www.intel.com/design/pentiumii/manuals/243191.htm
Microsoft提供可協助您尋找技術支援的第三方連絡資訊。這份連絡資訊可能會變更恕不另行通知。Microsoft 則否保證此第三方連絡資訊的正確性。

屬性

文章編號: 923247 - 上次校閱: 2012年3月22日 - 版次: 1.0
這篇文章中的資訊適用於:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Express Edition with Advanced Services
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Enterprise Edition for Itanium Based Systems
  • Microsoft SQL Server 2005 Enterprise X64 Edition
  • Microsoft SQL Server 2005 Standard Edition for Itanium Based Systems
  • Microsoft SQL Server 2005 Standard X64 Edition
  • Microsoft SQL Server 2008 Standard
  • Microsoft SQL Server 2008 R2 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Express with Advanced Services
  • Microsoft SQL Server 2008 Workgroup
  • Microsoft SQL Server 2008 Standard Edition for Small Business
關鍵字:?
kbtshoot kbexpertiseadvanced kbsql2005engine kbinfo kbmt KB923247 KbMtzh
機器翻譯
重要:本文是以 Microsoft 機器翻譯軟體翻譯而成,而非使用人工翻譯而成。Microsoft 同時提供使用者人工翻譯及機器翻譯兩個版本的文章,讓使用者可以依其使用語言使用知識庫中的所有文章。但是,機器翻譯的文章可能不盡完美。這些文章中也可能出現拼字、語意或文法上的錯誤,就像外國人在使用本國語言時可能發生的錯誤。Microsoft 不為內容的翻譯錯誤或客戶對該內容的使用所產生的任何錯誤或損害負責。Microsoft也同時將不斷地就機器翻譯軟體進行更新。
按一下這裡查看此文章的英文版本:923247
Microsoft及(或)其供應商不就任何在本伺服器上發表的文字資料及其相關圖表資訊的恰當性作任何承諾。所有文字資料及其相關圖表均以「現狀」供應,不負任何擔保責任。Microsoft及(或)其供應商謹此聲明,不負任何對與此資訊有關之擔保責任,包括關於適售性、適用於某一特定用途、權利或不侵權的明示或默示擔保責任。Microsoft及(或)其供應商無論如何不對因或與使用本伺服器上資訊或與資訊的實行有關而引起的契約、過失或其他侵權行為之訴訟中的特別的、間接的、衍生性的損害或任何因使用而喪失所導致的之損害、資料或利潤負任何責任。

提供意見

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com