SQL Server 2005 以降のバージョンで発生する DBCC エラー 2570 のトラブルシューティング

適用対象: Microsoft SQL Server 2005 Standard EditionMicrosoft SQL Server 2005 Developer EditionMicrosoft SQL Server 2005 Enterprise Edition

はじめに


この資料では、SQL Server エラー 2570、エラーの原因と問題を解決する方法について説明します。

詳細


DATA_PURITY チェック

SQL Server 2005 で DBCC CHECKDB および DBCC CHECKTABLE コマンドを DATA_PURITY、新しいオプションが追加されました。このオプションを有効に、DBCC CHECKDB または DBCC CHECKTABLE コマンドを実行すると、コマンドは、テーブルまたはデータベース内のテーブルのすべての行の各列の値に「データの純粋性」の検証を実行します。列内の値が有効であることを確認するのにはこれらの新しいチェックを実行 (つまり、値の範囲外のドメインではないことに関連付けられている列のデータ型)。実行される検証の本質は、列のデータ型によって異なります。次のすべてを網羅したリストは、いくつかの例を示します。
列のデータ型実行されるデータ検証の種類
Unicode 文字データの長さは、2 の倍数である必要があります。
日付時刻日数] フィールドは、1753 年 1 月および 12 月 31 日間でする必要があります 9999 です。[時刻] フィールドは、'11:59:59:999 PM' よりも前である必要があります。
現実および浮動小数ある snan は関係、QNAN、NINF、ND、PD、PINF などの無効な浮動小数点値の存在を確認します。
すべてのデータ型列のデータの妥当性がチェックされます。だけチェックは、格納された値が範囲外にすることも可能です。たとえば、 tinyintデータ型を選択し、0 255 までからの範囲が無効です (0 から 255 までの値を格納できるだけ)、1 バイトに格納されて、チェックのため、値は必要。

すべてのデータベースに対してデータの純度の妥当性検査は自動的に使用できません。いくつかの要因によっては、チェックが有効になります。
  • SQL Server 2005 およびそれ以降のバージョンで作成されたデータベースでは、これらのチェックは既定で有効になっているし、を無効にできません、ため、DBCC CHECKDB または DBCC CHECKTABLE コマンドを実行するときに、DATA_PURITY オプションの使用には関係ありません。
  • など、SQL Server 2000、SQL Server 7.0、および SQL Server 2005 にアップグレードしたバージョンの SQL Server の以前のバージョンで作成されたデータベースのこれらのチェックは既定で有効になりません。これらのチェックを実行するためには、DBCC CHECKDB または DBCC CHECKTABLE コマンドに DATA_PURITY オプションを指定する必要があります。これにより、2 つのこと。
    • DBCC コマンドが終了し、データベースがクリーンでは、すべてのデータの純度チェックを含むことを報告します。このファクトは、データベース ヘッダーに記録されます。すべての DBCC CHECKDB または DBCC CHECKTABLE コマンドの実行はこの情報とデータ純度チェックが表示され、SQL Server 2005 で作成されたデータベースのように自動的に実行されます。つまり、データベースを「クリーン」が判明すると、データの純度チェックが必ず実行されます。
    • DBCC コマンドは終了ですが、データの不整合の問題を報告します。大文字と小文字の場合は、不整合を修復するデータベースをクリーンアップする必要があるして DBCC コマンドを再度実行ましょう。データベースがクリーンに報告されるまでは、DBCC コマンドに DATA_PURITY オプションを指定する必要があります。
  • PHYSICAL_ONLY オプションを指定するは、DBCC CHECKDB または DBCC CHECKTABLE コマンドを実行すると、データの純度チェックは実行されません。

現象

無効または範囲外のデータが保存されている以前のバージョンの SQL Server データベースで次の理由。
  • 無効なデータが bcp ユーティリティなどの一括挿入のメソッドを使用しているときにソースに存在していた。
  • SQL Server への RPC イベント呼び出しから無効なデータが渡されました。
  • 他の可能性のある原因物理データの破損を左の列の値が無効です。
テーブルの列に無効なデータがあれば、無効なデータに対して実行される操作の種類によって問題が発生する可能性があります。しかし、問題はありませんし、無効なデータが SQL Server 2005 およびそれ以降のバージョンで、DBCC CHECKDB または DBCC CHECKTABLE コマンドを実行するまでは発見できないこともできます。

無効なデータが存在するのですることがあります現象のいくつかが含まれます (ただしに制限されません)。
  • アクセス違反やその他の影響を受ける列に対してクエリを実行中に例外です。
  • 誤った結果が影響を受ける列に対して実行されたクエリによって返されます。
  • エラーまたは問題の影響を受ける列に対して統計が作成されるとします。
  • 次のようなエラー メッセージ:
    Msg 9100、レベル 23、状態 2、行 1 つのインデックス破損を検出しました。DBCC CHECKDB を実行します。

DATA_PURITY 問題のレポート

DBCC CHECKDB または DBCC CHECKTABLE のコマンドに DATA_PURITY オプションを有効に (または、データ純度チェックが自動的に実行されます)、および無効なを実行するときは、DBCC コマンドによってチェックされているテーブルにデータが存在する、DBCC の出力には、データに関する問題を示す追加のメッセージが含まれています。データの純度問題を示すいくつかのサンプル エラー メッセージを次に示します。
DBCC は、"account_history"の結果します。
Msg 2570、レベル 16、状態 2、行 1
ページ (1:1073)、スロットの 33 のオブジェクト ID 1977058079、インデックス ID 0、パーティション ID 129568478265344、割り当ての単位 ID 129568478265344 (型「行内データ」) を付けます。"Account_name_japan"の列の値は、nvarchar のデータ型の範囲外です。有効な値に列を更新します。

Msg 2570、レベル 16、状態 2、行 1
ページ (1:1156)、スロットの 120 のオブジェクト ID 1977058079、インデックス ID 0、パーティション ID 129568478265344、割り当ての単位 ID 129568478265344 (型「行内データ」) を付けます。"Account_name_japan"の列の値は、nvarchar のデータ型の範囲外です。有効な値に列を更新します。
オブジェクト"account_history"の 1080 のページには、153137 の行があります。
CHECKDB では、"account_history"(オブジェクト ID 1977058079) のテーブルの割り当てエラーと 338 の一貫性エラーを参照してください。
CHECKDB では、データベース 'BadUnicodeData' のアロケーション エラーと 338 の一貫性エラーを参照してください。
DBCC の実行が完了しました。DBCC がエラー メッセージを出力した場合は、システム管理者に問い合わせてください。
'Table1' の DBCC 結果です。
Msg 2570、レベル 16、状態 3、行 1
ページ (1:154)、スロット 0 のオブジェクト ID 2073058421、インデックス ID 0、パーティション ID 72057594038321152、割り当て単位 ID 72057594042318848 (型「行内データ」) を作成。列"col2"の値は、「実際」のデータ型の範囲外です。有効な値に列を更新します。
オブジェクト「テーブル 1」の 2 つのページには、4 行があります。
CHECKDB では、0 の割り当てエラーと (オブジェクト ID 2073058421) テーブル 'テーブル 1' の 1 の一貫性エラーが見つかりました。
CHECKDB では、データベース 'realdata' のアロケーション エラーは 0 と 1 の一貫性エラーを参照してください。DBCC の実行が完了しました。DBCC がエラー メッセージを出力した場合は、システム管理者に問い合わせてください。
DBCC は、'table2' の結果です。
Msg 2570、レベル 16、状態 3、行 1
(1:155) のページ、オブジェクト ID 2105058535 で 0 をスロット、インデックス ID 0、パーティション ID 72057594038452224、割り当て単位 ID 72057594042449920 (型「行内データ」)。列"col2"の値は、「10 進」のデータ型の範囲外です。有効な値に列を更新します。
オブジェクト「テーブル 2」の 1 ページに 4 行があります。
CHECKDB では、0 の割り当てエラーと (オブジェクト ID 2105058535) テーブル 'テーブル ' が 2 の 1 の一貫性エラーが見つかりました。
CHECKDB では、データベース 'realdata' のアロケーション エラーは 0 と 1 の一貫性エラーを参照してください。DBCC の実行が完了しました。DBCC がエラー メッセージを出力した場合は、システム管理者に問い合わせてください。
DBCC は、'テーブル 3' の結果です。
Msg 2570、レベル 16、状態 3、行 1
ページ (1:157)、スロット 0 のオブジェクト ID 2121058592、インデックス ID 0、パーティション ID 72057594038517760、割り当て単位 ID 72057594042515456 (型「行内データ」) を作成。列"col2"の値は、"datetime"のデータ型の範囲外です。有効な値に列を更新します。
オブジェクト」テーブル 3」の 1 ページには、3 つの行があります。
CHECKDB では、0 の割り当てエラーと (オブジェクト ID 2121058592) テーブル 'テーブル ' が 3 の 1 の一貫性エラーが見つかりました。
CHECKDB では、データベース 'realdata' のアロケーション エラーは 0 と 1 の一貫性エラーを参照してください。DBCC の実行が完了しました。DBCC がエラー メッセージを出力した場合は、システム管理者に問い合わせてください。
無効な列値を含むすべての行については、2570 エラーが生成されます。

データの純度問題を修正します。

2570 エラーは、DBCC 修復オプションのいずれかを使用して修復できません。DBCC がどのような値が無効な列の値を置き換えるために使用する必要がありますを決定する可能性がないためにです。したがって、列の値を手動で更新する必要があります。

を手動で更新を実行するのには、問題のある行を見つけるにあります。これを実現する 2 とおりの方法があります。
  • 無効な値を含む行を検索するのには無効な値を含むテーブルに対してクエリを実行します。
  • 2570 エラーからの情報を使用すると、無効な値を持つ行を識別します。
ここで取り上げる以下に詳細にこれらのメソッドの両方を無効なデータを持つ行を検索する例を使用します。

正しい行を見つけたら、決定する必要があります既存の無効なデータの交換に使用される新しい値にします。この決定をするアプリケーションの動作の値の範囲に基づいて非常に慎重に行われますが、その特定の行のデータの論理的な意味だけでなく。使用できる選択肢は次のとおりです。
  • どのような値がわかっている場合は、その特定の値に設定します。
  • 使用可能な既定値に設定します。
  • 列の値は NULL に設定します。
  • 列のデータ型の最大値または最小値に列の値を設定します。
  • 特定の行は列の有効な値を持たないすべての使用のないことと思われる場合にその行を削除できます。

T SQL クエリを使用して、無効な値を持つ行を検索します。

無効な値を持つ行を検索するために実行する必要があるクエリの種類は、問題を報告する列のデータ型によって異なります。2570 エラー メッセージを見ると、これに役立つ情報の 2 つの重要な部分が表示されます。次の例では、"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

Float データ型:
-- 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
10 進数および数値データ型。
SELECT col1 FROM table2
WHERE col2 > 9999999999.99999
OR col1 < -9999999999.99999
有効桁数と小数点部桁数の 10 進数または数値の列を定義するに基づく値を調整する必要があることに注意してください。上記の例では、col2 の decimal(15,5) として定義された列です。

日付時刻データ型。
日付時刻列の無効な値を含む行を識別する 2 つの異なるクエリを実行する必要があります。
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)、スロット 0 のオブジェクト ID 2121058592、インデックス ID 0、パーティション ID 72057594038517760、割り当て単位 ID 72057594042515456 (型「行内データ」) を作成。列"col2"の値は、"datetime"のデータ型の範囲外です。有効な値に列を更新します。
このメッセージの情報が表示されます: ページ (1:157)、スロット 0 です。行を識別する必要がある情報です。ファイル Id は 1、< は 157、スロット Id は 0 です。この情報を作成したら、次のように、コマンドを実行するために必要になります。
DBCC TRACEON ( 3604 )
DBCC PAGE ( realdata , 1 , 157 , 3 )
このコマンドは、ページの内容全体を印刷します。DBCC PAGE コマンドへのパラメーターは次のとおりです。
  • データベース名
  • ファイル Id
  • 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 = 1 Slot 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 に格納されている行が必要です。エラー メッセージをその col2 には、問題の 1 つがわかります。スロット 0 の列 1 の値を取得し、update ステートメントの WHERE 句の述語として使用したり、ステートメントを削除できます。

警告最初のメソッド (つまり、T SQL クエリを使用、必要な情報を検索する) を使用することをお勧めします。最後の手段として、ページの DBCC コマンドを使用します。運用環境でこのコマンドを使用するときに、最大限の注意を払います。テスト サーバーの運用データベースを復元し、DBCC PAGE を使用してすべての必要な情報を取得するとし、運用サーバー上で更新を行うことをお勧めします。同様に、必ず問題が発生し、データベースの以前のコピーを元に戻す必要がある場合に備えて、バックアップの準備ができてを保管します。

関連情報


DBCC CHECKDB ステートメントの詳細については、次の Microsoft Developer Network (MSDN) Web サイトの「DBCC CHECKDB (Transact SQL)」のトピックを参照してください。SQL Server 2000 での既知の問題に関する詳細については、マイクロソフト サポート技術情報の記事を表示するのには次の資料番号をクリックします。
900335の修正: FLOAT データ型または REAL データ型の場合は、インデックスが含まれていて、このデータ型には、NaN 値が含まれている場合、SQL Server 2000 データベースの自動リカバリ ・ オペレーションが成功せず

RPC イベントの詳細については、次の MSDN Web サイトで「呼び出すストアド プロシージャ (OLE DB)」のトピックを参照してください。異なるデータ型の詳細については、次の MSDN Web サイトで「呼び出すストアド プロシージャ (OLE DB)」のトピックを参照してください。浮動ポイント値の規則の詳細については、以下のインテル Web サイトを参照してください。他社テクニカル サポートのお問い合わせ窓口は、ユーザーの便宜のために提供されているものであり、この連絡先情報は予告なしに変更される場合があります。マイクロソフトは、掲載されている情報に対して、いかなる責任も負わないものとします。