• [アーティクル]

DBCC CHECKDB (Transact-SQL)

次の操作を実行し、指定したデータベース内のすべてのオブジェクトの論理的および物理的な整合性をチェックします。

  • データベースに対して DBCC CHECKALLOC を実行。

  • データベース内にあるすべてのテーブルとビューに対して DBCC CHECKTABLE を実行。

  • データベースに対して DBCC CHECKCATALOG を実行。

  • データベース内にあるすべてのインデックス付きビューの内容を検証。

  • FILESTREAM を使用して varbinary(max) データをファイル システムに格納する場合のテーブルのメタデータとファイル システムのディレクトリおよびファイルの間のリンクレベルの一貫性を検証。

  • データベースの Service Broker データを検証。

DBCC CHECKALLOC、DBCC CHECKTABLE、または DBCC CHECKCATALOG コマンドは、DBCC CHECKDB と別に実行する必要はありません。これらのコマンドで実行されるチェックに関する詳細については、各コマンドの説明を参照してください。

トピック リンク アイコンTransact-SQL 構文表記規則

構文

DBCC CHECKDB 
[
    [ (database_name | database_id | 0
        [ , NOINDEX 
        | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
    ) ]
    [ WITH 
        {
            [ ALL_ERRORMSGS ]
            [ , EXTENDED_LOGICAL_CHECKS ] 
            [ , NO_INFOMSGS ]
            [ , TABLOCK ]
            [ , ESTIMATEONLY ]
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]
        }
    ]
]

引数

  • database_name | database_id | 0
    整合性チェックを実行するデータベースの名前または ID です。指定しない場合、または 0 を指定した場合は、現在のデータベースが使用されます。データベース名は、識別子のルールに従っている必要があります。

  • NOINDEX
    ユーザー テーブルの非クラスター化インデックスの集中チェックを実行しないように指定します。これにより、全体の実行時間が短縮されます。整合性チェックは、常にすべてのシステム テーブルのインデックスに対して実行されるため、NOINDEX はシステム テーブルに対しては無効です。

  • REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
    検出されたエラーを DBCC CHECKDB が修復するように指定します。修復オプションを使用するには、指定するデータベースがシングル ユーザー モードになっている必要があります。以下の修復オプションを使用できます。

    • REPAIR_ALLOW_DATA_LOSS
      報告されたすべてのエラーの修復を試みます。修復を実行すると、データが失われることがあります。

    • REPAIR_FAST
      旧バージョンとの互換性のためにのみ、構文が用意されています。修復操作は実行されません。

    • REPAIR_REBUILD
      データ損失の可能性がない修復を実行します。これには、非クラスター化インデックスの存在しない行の修復など時間のかからない修復操作と、インデックスの再構築など時間のかかる修復操作が含まれます。

      REPAIR_REBUILD では、FILESTREAM データに関係するエラーは修復されません。

    重要な注意事項重要

    REPAIR オプションは、最後の手段としてだけ使用してください。エラーの修復では、バックアップから復元することをお勧めします。修復操作では、テーブルまたはテーブル間に制約があっても考慮されません。指定したテーブルに 1 つでも関連する制約がある場合は、修復操作の後に DBCC CHECKCONSTRAINTS を実行することをお勧めします。REPAIR を使用する必要がある場合は、修復オプションを指定せずに DBCC CHECKDB を実行して、使用する修復レベルを確認してください。REPAIR_ALLOW_DATA_LOSS レベルを使用する場合は、このオプションを指定して DBCC CHECKDB を実行する前に、データベースをバックアップすることをお勧めします。

  • ALL_ERRORMSGS
    オブジェクトごとに、報告されているすべてのエラーを表示します。既定では、すべてのエラー メッセージが表示されます。そのため、このオプションを指定しても省略しても影響はありません。tempdb データベースから生成されるメッセージを除き、エラー メッセージは、オブジェクト ID を基準として並べ替えられます。

    SQL Server Management Studio では、返される最大エラー メッセージ番号は 1000 です。ALL_ERRORMSGS を指定する場合は、必要に応じて Management Studio で DBCC CHECKDB を複数回実行し、エラーの完全な一覧を取得します。ALL_ERRORMSGS を指定する場合は、sqlcmd ユーティリティを使用して DBCC コマンドを実行するか、SQL Server のエージェント ジョブをスケジュールして DBCC コマンドを実行し、ファイルに出力することをお勧めします。どちらの方法でも、コマンドを 1 回実行するとすべてのエラー メッセージが出力されます。

  • EXTENDED_LOGICAL_CHECKS
    互換性レベルが 100 (SQL Server 2008) 以上の場合、インデックス付きビュー、XML インデックス、および空間インデックス (存在する場合) について、論理的な一貫性をチェックします。

    詳細については、このトピックの「解説」の「インデックスに対する論理的な一貫性チェックの実行」を参照してください。

  • NO_INFOMSGS
    すべての情報メッセージを表示しないようにします。

  • TABLOCK
    DBCC CHECKDB が、内部データベースのスナップショットを使用せずに、ロックを取得します。これにはデータベースの短期の排他 (X) ロックも含まれます。TABLOCK の作用によって負荷の高いデータベースでも DBCC CHECKDB の実行速度が速くなりますが、DBCC CHECKDB の実行中はデータベースでの同時実行性が低下します。ロックの詳細については、「ロック モード」を参照してください。

    TABLOCK では実行されるチェックが制限されます。DBCC CHECKCATALOG はデータベースに対して実行されず、Service Broker データは検証されません。

  • ESTIMATEONLY
    必要な他のオプションをすべて指定した状態で、DBCC CHECKDB の実行時に必要となる tempdb 領域の予測サイズを表示します。実際のデータベースのチェックは行われません。

  • PHYSICAL_ONLY
    チェック内容を、ページとレコード ヘッダーの物理構造の整合性、およびデータベースの割り当ての一貫性に限定します。このチェックは、データベースの物理的一貫性に関する低オーバーヘッド チェックを提供するように設計されているため、ユーザーのデータが損傷する可能性のある破損ページやチェックサム エラー、および一般的なハードウェア障害も検出できます。

    完全な DBCC CHECKDB を実行すると、完了するまでに以前のバージョンよりはるかに時間がかかることがあります。原因は次のとおりです。

    • 論理チェックの対象範囲が広がった。

    • チェック対象の、基になる構造の一部が複雑になった。

    • 新機能を含めるために多数の新しいチェックが導入された。

    したがって、大規模なデータベースでは、PHYSICAL_ONLY オプションを使用すると DBCC CHECKDB の実行時間が大幅に短縮されることがあるため、実稼働システムで頻繁に使用する場合はこのオプションを使用することをお勧めします。ただし、完全な DBCC CHECKDB を定期的に実行することもお勧めします。実行する頻度は、それぞれの業務環境や運用環境に固有の要因によって異なります。

    PHYSICAL_ONLY を指定した場合は常に NO_INFOMSGS も暗黙的に指定されるため、修復オプションを同時指定することはできません。

    注意注

    PHYSICAL_ONLY を指定すると、DBCC CHECKDB で FILESTREAM データのチェックがすべてスキップされるようになります。

  • DATA_PURITY
    DBCC CHECKDB が、データベース内の、値が無効または範囲外の列をチェックします。たとえば、DBCC CHECKDB は、datetime 型の許容範囲外となる日時の値を含む列や、小数点以下桁数または有効桁数の値が有効ではない decimal 型や概数型の列を検出します。

    SQL Server 2005 以降で作成されたデータベースでは、列の値の整合性チェックは既定で有効になっているため、DATA_PURITY オプションを指定する必要はありません。以前のバージョンの SQL Server からアップグレードしたデータベースの場合は、列の値のチェックは既定では有効になっていないため、データベースで DBCC CHECKDB WITH DATA_PURITY を実行します。エラーなく実行されると、その後、DBCC CHECKDB は既定で列の値の整合性をチェックします。以前のバージョンの SQL Server からのデータベースのアップグレードによる CHECKDB への影響の詳細については、後の「解説」を参照してください。

    PHYSICAL_ONLY を指定した場合は、列の整合性チェックは行われません。

    DBCC 修復オプションを使用して、このオプションによって報告された検証エラーを修正することはできません。これらのエラーを手動で修正する方法の詳細については、サポート技術情報の資料 923247「SQL Server 2005 での DBCC エラー 2570 のトラブルシューティング」を参照してください。

説明

以前のバージョンの SQL Server の場合、テーブルごと、およびインデックスごとの行数やページ数の値が正しくならないことがあります。特定の状況では、これらの値が負の値になることもあります。SQL Server 2005 以降では、値が常に正しく保たれます。したがって、SQL Server 2005 以降で作成されたデータベースに間違った行数やページ数が含まれることはありませんが、SQL Server 2005 以降にアップグレードされたデータベースには含まれる可能性があります。この場合、データベースに格納されているデータが破損しているわけではありません。DBCC CHECKDB は拡張され、これらの値が 1 つでも負の値になると検出されるようになっています。負の値が検出されると、DBCC CHECKDB の出力に警告が表示され、推奨される解決方法として DBCC UPDATEUSAGE を実行するよう示されます。

DBCC CHECKDB は、無効なインデックスについては検査しません。無効なインデックスの詳細については、「インデックスの無効化」を参照してください。

ユーザー定義型がバイト順としてマークされている場合、シリアル化されたユーザー定義型は 1 つだけ存在する必要があります。シリアル化されたバイト順のユーザー定義型が一貫して存在していない場合、DBCC CHECKDB の実行中にエラー 2537 が発生します。詳細については、「ユーザー定義型の要件」を参照してください。

Resource データベースはシングル ユーザー モードでしか修正できないため、このデータベースに対して DBCC CHECKDB コマンドを直接実行することはできません。ただし、DBCC CHECKDB を master データベースに対して実行すると、内部的に次の CHECKDB が Resource データベースに対して実行されます。このため、DBCC CHECKDB が追加の結果を返す場合があります。このコマンドでは、オプションが設定されていないか、PHYSICAL_ONLY または ESTIMATEONLY オプションが設定されている場合に、追加の結果セットが返されます。

SP2 より前のバージョンの SQL Server 2005 で DBCC CHECKDB を実行すると、SQL Server インスタンスのプラン キャッシュが消去されます。プラン キャッシュが消去されると、後続のすべての実行プランが再コンパイルされ、場合によっては、クエリ パフォーマンスが一時的に急激に低下します。SP2 以降では、DBCC CHECKDB を実行してもプラン キャッシュは消去されません。

インデックスに対する論理的な一貫性チェックの実行

インデックスに対する論理的な一貫性チェックは、データベースの互換性レベルによって次のように異なります。

  • 互換性レベルが 100 (SQL Server 2008) 以上の場合

    • NOINDEX が指定されていない場合、DBCC CHECKDB は、1 つのテーブルとそのすべての非クラスター化インデックスについて、物理的な一貫性と論理的な一貫性の両方をチェックします。ただし、XML インデックス、空間インデックス、およびインデックス付きビューでは、既定で物理的な一貫性のみがチェックされます。

    • WITH EXTENDED_LOGICAL_CHECKS が指定されている場合、インデックス付きビュー、XML インデックス、および空間インデックス (存在する場合) に対して論理チェックが実行されます。既定では、論理的な一貫性のチェック前に物理的な一貫性がチェックされます。NOINDEX も指定されている場合は、論理チェックのみが実行されます。

      この論理的な一貫性のチェックでは、インデックス オブジェクトの内部インデックス テーブルが参照先のユーザー テーブルと照合されます。行の不整合を検出するために、内部テーブルとユーザー テーブルの完全な積集合を実行する内部クエリが作成されます。このクエリを実行するとパフォーマンスに多大な影響を及ぼす可能性があり、その進行状況は追跡できません。したがって、物理的な破損とは無関係のインデックスの問題があると考えられる場合、またはページ レベルのチェックサムがオフになっており、列レベルのハードウェアの破損が考えられる場合にのみ、WITH EXTENDED_LOGICAL_CHECKS を指定することをお勧めします。

    • インデックスがフィルター選択されたインデックスである場合、DBCC CHECKDB は一貫性チェックを実行して、インデックス エントリがフィルター述語に適合していることを確認します。

  • 互換性レベルが 90 以下で NOINDEX が指定されていない場合、DBCC CHECKDB は、1 つのテーブルまたはインデックス付きビューと、そのすべての非クラスター化インデックスおよび XML インデックスについて、物理的な一貫性と論理的な一貫性の両方をチェックします。空間インデックスはサポートされません。

データベースの互換性レベルを調べるには

内部データベース スナップショット

DBCC CHECKDB では、チェックの実行に必要なトランザクションの一貫性を得るため、内部データベース スナップショットを使用します。これにより、コマンド実行時のブロックや同時実行の問題を回避できます。詳細については、「データベース スナップショットのスパース ファイルのサイズについて」、および「DBCC (Transact-SQL)」の「DBCC 内部データベース スナップショットの使用」を参照してください。スナップショットを作成できない場合や TABLOCK が指定されていない場合、DBCC CHECKDB はロックを取得して必要な一貫性を実現します。この場合、割り当てのチェックを行うための排他データベース ロックと、テーブルのチェックを行うための共有テーブル ロックが必要です。

DBCC CHECKDB を master に対して実行し、内部データベース スナップショットを作成できない場合、DBCC CHECKDB は失敗します。

tempdb に対して DBCC CHECKDB を実行しても、割り当てまたはカタログのチェックは行われず、共有テーブル ロックを取得してテーブルのチェックを行う必要があります。これは、パフォーマンス上の理由から、tempdb ではデータベースのスナップショットを利用できないためです。つまり、必要なトランザクションの一貫性を実現できません。

FILESTREAM データのチェックと修復

データベースとテーブルに対して FILESTREAM が有効になっている場合、varbinary(max) バイナリ ラージ オブジェクト (BLOB) をファイル システムに格納することもできます。BLOB をファイル システムに格納するデータベースに対して DBCC CHECKDB を使用する場合は、DBCC によって、ファイル システムとデータベースの間のリンクレベルの一貫性がチェックされます。

たとえば、テーブルに FILESTREAM 属性を使用する varbinary(max) 列が含まれている場合、DBCC CHECKDB は、ファイル システムのディレクトリおよびファイルと、テーブルの行、列、および列の値とが一対一でマップされていることをチェックします。REPAIR_ALLOW_DATA_LOSS オプションを指定すると、DBCC CHECKDB で破損を修復できます。FILESTREAM の破損を修復するため、DBCC はファイル システム データが存在しないテーブル行をすべて削除します。

ベスト プラクティス

実稼働システムで頻繁に使用する場合は PHYSICAL_ONLY オプションを使用することをお勧めします。PHYSICAL_ONLY を使用すると、大規模データベースでの DBCC CHECKDB の実行時間を大幅に短縮できます。また、定期的に、オプションを指定せずに DBCC CHECKDB を実行することもお勧めします。DBCC CHECKDB を実行する頻度は、個々の業務とその運用環境によって変わります。

オブジェクトの並列チェック

既定では、DBCC CHECKDB はオブジェクトの並列チェックを実行します。並列処理の次数は、クエリ プロセッサによって自動的に決定されます。並列処理の次数の最大値は、並列クエリと同様に構成します。DBCC チェックに利用できるプロセッサの最大数を制限するには、sp_configure を使用します。詳細については、「max degree of parallelism オプション」を参照してください。並列チェックはトレース フラグ 2528 を使用して無効にできます。詳細については、「トレース フラグ (Transact-SQL)」を参照してください。

DBCC エラー メッセージについて

DBCC CHECKDB コマンドの終了後、メッセージが SQL Server エラー ログに書き込まれます。DBCC コマンドが正常に実行された場合、メッセージでは正常に処理されたこととコマンドの実行時間が示されます。エラーが発生して DBCC コマンドが完了前に停止した場合、メッセージではコマンドが終了したことと、状態の値、およびコマンド実行時間が示されます。次の表は、メッセージに含まれる可能性がある状態値の一覧と説明です。

状態

説明

0

エラー番号 8930 が発生しました。このエラーは、メタデータの破損により DBCC コマンドが終了したことを示します。

1

エラー番号 8967 が発生しました。内部 DBCC エラーがあります。

2

緊急モードのデータベース修復中にエラーが発生しました。

3

このエラーは、メタデータの破損により DBCC コマンドが終了したことを示します。

4

アサートまたはアクセス違反が検出されました。

5

不明なエラーが発生し、DBCC コマンドが終了しました。

エラー報告の使用

DBCC CHECKDB により破損エラーが検出されるたびに、ダンプ ファイル (SQLDUMPnnnn.txt) が SQL Server の LOG ディレクトリに生成されます。機能の使用状況データ収集とエラー報告機能が SQL Server インスタンスに対して有効になっている場合、ダンプ ファイルは自動的に Microsoft に転送されます。収集されたデータは SQL Server の機能向上のために使用されます。

このダンプ ファイルには、DBCC CHECKDB コマンドの結果と追加の診断出力が含まれます。ダンプ ファイルにアクセスできるのは、SQL Server サービス アカウントと sysadmin ロールのメンバーだけです。既定では、sysadmin ロールには Windows の BUILTIN\Administrators グループとローカルの管理者グループのすべてのメンバーが含まれます。データ収集プロセスが失敗しても、DBCC コマンドは失敗しません。

エラーの解決

DBCC CHECKDB でエラーが報告された場合は、REPAIR を REPAIR オプションのいずれかを指定して実行するのではなく、データベースのバックアップからデータベースを復元することをお勧めします。バックアップが存在しない場合は、修復を実行することによって報告されたエラーを修正します。使用する修復オプションは、報告されたエラーの一覧の最後に指定されています。ただし、REPAIR_ALLOW_DATA_LOSS オプションを使用してエラーを修正する場合は、一部のページ (データ) が削除されることがあります。

状況によっては、データベースに、列のデータ型に対して有効ではない値や範囲外の値が入力されていることがあります。SQL Server 2000 では、DBCC CHECKDB は、これらの列の値に関する範囲や整合性のチェックを行いません。それに対し、SQL Server 2005 以降の DBCC CHECKDB は、すべての列のデータ型について有効ではない列の値を検出します。したがって、以前のバージョンの SQL Server からアップグレードしたデータベースに対して DATA_PURITY オプションを指定して DBCC CHECKDB を実行すると、以前から存在していた列の値のエラーが検出される場合があります。SQL Server ではこれらのエラーを自動的に修復することはできないため、列の値を手動で更新する必要があります。CHECKDB でこのようなエラーが検出されると、CHECKDB は警告 (エラー番号 2570) を返し、影響を受ける行を特定してエラーを手動で修正するための情報を示します。

ユーザー トランザクションを利用して修復を実行できるので、後からユーザーが変更をロールバックすることができます。修復をロールバックしたときは、データベースにエラーが残っているので、データベースをバックアップから復元する必要があります。修復が完了したら、データベースをバックアップします。

データベース緊急モードでのエラーの解決

ALTER DATABASE ステートメントによってデータベースが緊急モードに設定されている場合、REPAIR_ALLOW_DATA_LOSS オプションを指定して DBCC CHECKDB を実行すると、データベースに対していくつかの特別な修復を実行できます。このような修復により、通常は復旧不可能なデータベースを、物理的な一貫性のある状態でオンラインに戻すことができる場合があります。このような修復は、バックアップからデータベースを復元できない場合にのみ、最終的な手段として使用してください。データベースが緊急モードに設定されている場合、データベースは READ_ONLY になり、ログ記録は無効になります。このとき、固定サーバー ロール sysadmin のメンバー以外はデータベースにアクセスできません。

注意注

ユーザー トランザクション内で DBCC CHECKDB コマンドを緊急モードで実行したり、実行後にトランザクションをロールバックすることはできません。

データベースが緊急モードのときに、REPAIR_ALLOW_DATA_LOSS 句を指定して DBCC CHECKDB を実行した場合は、次の処理が行われます。

  • DBCC CHECKDB では、I/O エラーまたはチェックサム エラーが原因でアクセス不可とマークされたページが、エラーが発生しなかった場合と同様に使用されます。これにより、データベースからのデータ復旧の可能性が高くなります。

  • DBCC CHECKDB では、標準的なログ ベースの復旧方法により、データベースの復旧が試行されます。

  • トランザクション ログが壊れているためにデータベース復旧が失敗した場合、トランザクション ログは再構築されます。ただし、トランザクション ログの再構築の結果、トランザクションの一貫性が失われる場合があります。

DBCC CHECKDB コマンドが正常に終了した場合、データベースでは物理的な一貫性が保たれ、データベースの状態は ONLINE に設定されます。ただし、データベースにはトランザクション上一貫しない部分が 1 つ以上含まれる可能性があります。DBCC CHECKCONSTRAINTS コマンドを実行してビジネス ロジックの不備を確認し、直ちにデータベースをバックアップすることをお勧めします。

DBCC CHECKDB コマンドが失敗した場合、データベースを修復することはできません。

レプリケートされたデータベースでの、REPAIR_ALLOW_DATA_LOSS を指定した DBCC CHECKDB の実行

REPAIR_ALLOW_DATA_LOSS オプションを指定して DBCC CHECKDB コマンドを実行すると、レプリケーションで使用されるユーザー データベース (パブリケーション データベースおよびサブスクリプション データベース) とディストリビューション データベースに影響が生じる場合があります。パブリケーション データベースとサブスクリプション データベースには、パブリッシュされたテーブルとレプリケーション メタデータ テーブルが含まれます。これらのデータベースでは、次の問題が発生する可能性があります。

  • パブリッシュされたテーブル。破損したユーザー データを修復するため CHECKDB 処理によって実行されるアクションが、レプリケートされない場合があります。

    • マージ レプリケーションではトリガーを使用して、パブリッシュされたテーブルに対する変更を追跡します。CHECKDB 処理で行が挿入、更新、または削除された場合、トリガーは起動しません。このため、変更はレプリケートされません。

    • トランザクション レプリケーションではトランザクション ログを使用して、パブリッシュされたテーブルに対する変更を追跡します。その後、ログ リーダー エージェントは変更をディストリビューション データベースに移動します。DBCC 修復の一部は、ログには記録されますが、ログ リーダー エージェントでレプリケートできません。たとえば、CHECKDB 処理によってデータ ページの割り当てが解除された場合、ログ リーダー エージェントではこの処理が DELETE ステートメントに変換されません。このため、変更はレプリケートされません。

  • レプリケーション メタデータ テーブル。破損したレプリケーション メタデータ テーブルを修復するため CHECKDB 処理で実行されるアクションでは、レプリケーションの削除と再構成が必要になります。

ユーザー データベースまたはディストリビューション データベースで、REPAIR_ALLOW_DATA_LOSS オプションを指定して DBCC CHECKDB コマンドを実行する必要がある場合は、次の手順に従います。

  1. システムを停止します。データベースの操作と、レプリケーション トポロジの他のすべてのデータベースの利用を停止した後、すべてのノードの同期を試行します。詳細については、「レプリケーション トポロジを停止する方法 (レプリケーション Transact-SQL プログラミング)」を参照してください。

  2. DBCC CHECKDB を実行します。

  3. DBCC CHECKDB レポートで、ディストリビューション データベースの任意のテーブルまたはユーザー データベースのレプリケーション メタデータ テーブルの修復が示されている場合は、レプリケーションを削除して再構成します。詳細については、「レプリケーションの削除」を参照してください。

  4. DBCC CHECKDB レポートで、レプリケートされたテーブルの修復が示されている場合は、データ検証を実行して、パブリケーション データベースとサブスクリプション データベースのデータ間に違いがあるかどうかを確認します。詳細については、「パブリッシャーとサブスクライバーのデータが一致しない」を参照してください。

結果セット

DBCC CHECKDB は以下の結果セットを返します。ESTIMATEONLY オプション、PHYSICAL_ONLY オプション、または NO_INFOMSGS オプションを指定した場合以外は、値が異なることがあります。

DBCC results for 'model'.

Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13.

Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5.

Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3.

Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3.

Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0.

Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0.

Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0.

DBCC results for 'sys.sysrowsetcolumns'.

There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'.

DBCC results for 'sys.sysrowsets'.

There are 97 rows in 1 pages for object 'sys.sysrowsets'.

DBCC results for 'sysallocunits'.

There are 195 rows in 3 pages for object 'sysallocunits'.

There are 0 rows in 0 pages for object "sys.sysasymkeys".

DBCC results for 'sys.syssqlguides'.

There are 0 rows in 0 pages for object "sys.syssqlguides".

DBCC results for 'sys.queue_messages_1977058079'.

There are 0 rows in 0 pages for object "sys.queue_messages_1977058079".

DBCC results for 'sys.queue_messages_2009058193'.

There are 0 rows in 0 pages for object "sys.queue_messages_2009058193".

DBCC results for 'sys.queue_messages_2041058307'.

There are 0 rows in 0 pages for object "sys.queue_messages_2041058307".

CHECKDB found 0 allocation errors and 0 consistency errors in database 'model'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

NO_INFOMSGS を指定した場合、DBCC CHECKDB は次の結果セット (メッセージ) を返します。

The command(s) completed successfully.

PHYSICAL_ONLY を指定した場合、DBCC CHECKDB は以下の結果セットを返します。

DBCC results for 'model'.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

ESTIMATEONLY を指定した場合、DBCC CHECKDB は以下の結果セットを返します。

Estimated TEMPDB space needed for CHECKALLOC (KB)

-------------------------------------------------

13

(1 row(s) affected)

Estimated TEMPDB space needed for CHECKTABLES (KB)

--------------------------------------------------

57

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

権限

sysadmin 固定サーバー ロールまたは db_owner 固定データベース ロールのメンバーシップが必要です。

例

A. 現在のデータベースと別のデータベースの両方をチェックする

次の例では、現在のデータベースと AdventureWorks2008R2 データベースに対して DBCC CHECKDB を実行します。

-- Check the current database.
DBCC CHECKDB;
GO
-- Check the AdventureWorks2008R2 database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks2008R2, NOINDEX);
GO

B. 情報メッセージを表示せずに現在のデータベースをチェックする

次の例では、現在のデータベースをチェックし、すべての情報メッセージを表示しないようにします。

DBCC CHECKDB WITH NO_INFOMSGS;
GO

変更履歴

変更内容

「FILESTREAM データのチェックと修復」セクションで、テーブルの行、列、および列の値にマップされない FILESTREAM ディレクトリとファイルが削除されることを示す内容が削除されました。