適用対象: ○SQL Server ○Azure SQL Database XAzure SQL Data Warehouse XParallel Data WarehouseAPPLIES TO: yesSQL Server yesAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

テーブルまたはインデックス付きビューを構成するすべてのページおよび構造の整合性チェックを行います。Checks the integrity of all the pages and structures that make up the table or indexed view.

トピック リンク アイコン Transact-SQL 構文表記規則Topic link icon Transact-SQL Syntax Conventions


    table_name | view_name    
    [ , { NOINDEX | index_id }    
    [ WITH     
        { [ ALL_ERRORMSGS ]    
          [ , EXTENDED_LOGICAL_CHECKS ]     
          [ , NO_INFOMSGS ]    
          [ , TABLOCK ]     
          [ , ESTIMATEONLY ]     
          [ , { PHYSICAL_ONLY | DATA_PURITY } ]     
          [ , MAXDOP = number_of_processors ]    


table_name | view_nametable_name | view_name
整合性チェックを行うテーブルまたはインデックス付きビューです。Is the table or indexed view for which to run integrity checks. テーブル名やビュー名は、識別子のルールに従っている必要があります。Table or view names must comply with the rules for identifiers.

ユーザー テーブルの非クラスター化インデックスの集中チェックを実行しないように指定します。Specifies that intensive checks of nonclustered indexes for user tables should not be performed. これにより、全体の実行時間が短縮されます。This decreases the overall execution time. 整合性チェックは、常にすべてのシステム テーブルのインデックスに対して実行されるため、NOINDEX はシステム テーブルに対しては無効です。NOINDEX does not affect system tables because the integrity checks are always performed on all system table indexes.

整合性チェックを行うインデックスの識別 (ID) 番号を指定します。Is the index identification (ID) number for which to run integrity checks. index_id を指定した場合、DBCC CHECKTABLE は、そのインデックスに対してのみ整合性チェックを行います (ヒープやクラスター化インデックスもチェックされます)。If index_id is specified, DBCC CHECKTABLE runs integrity checks only on that index, together with the heap or clustered index.

検出されたエラーを DBCC CHECKTABLE で修復するように指定します。Specifies that DBCC CHECKTABLE repair the found errors. 修復オプションを使用するには、データベースがシングル ユーザー モードになっている必要があります。To use a repair option, the database must be in single-user mode.

報告されたすべてのエラーの修復を試みます。Tries to repair all reported errors. 修復を実行すると、データが失われることがあります。These repairs can cause some data loss.

構文は、旧バージョンとの互換性のためにのみ残されています。Syntax is maintained for backward compatibility only. 修復操作は実行されません。No repair actions are performed.

データ損失の可能性がない修復を実行します。Performs repairs that have no possibility of data loss. これには、非クラスター化インデックスの存在しない行の修復など時間のかからない修復操作と、インデックスの再構築など時間のかかる修復操作が含まれます。This can include quick repairs, such as repairing missing rows in nonclustered indexes, and more time-consuming repairs, such as rebuilding an index.
この引数では、FILESTREAM データに関係するエラーは修復されません。This argument does not repair errors involving FILESTREAM data.


REPAIR オプションは、最後の手段としてのみ使用してください。Use the REPAIR options only as a last resort. エラーの修復では、バックアップから復元することをお勧めします。To repair errors, we recommend restoring from a backup. 修復操作では、テーブルまたはテーブル間に制約があっても考慮されません。Repair operations do not consider any of the constraints that may exist on or between tables. 指定したテーブルに 1 つでも関連する制約がある場合は、修復操作の後に DBCC CHECKCONSTRAINTS を実行することをお勧めします。If the specified table is involved in one or more constraints, we recommend running DBCC CHECKCONSTRAINTS after a repair operation. REPAIR を使用する必要がある場合は、修復オプションを指定せずに DBCC CHECKTABLE を実行して、使用する修復レベルを確認してください。If you must use REPAIR, run DBCC CHECKTABLE without a repair option to find the repair level to use. REPAIR_ALLOW_DATA_LOSS レベルを使用する場合は、このオプションを指定して DBCC CHECKTABLE を実行する前に、データベースをバックアップすることをお勧めします。If you are going to use the REPAIR_ALLOW_DATA_LOSS level, we recommend that you back up the database before you run DBCC CHECKTABLE with this option.

エラーを無制限に表示します。Displays an unlimited number of errors. 既定では、すべてのエラー メッセージが表示されます。All error messages are displayed by default. このオプションを指定しても省略しても影響はありません。Specifying or omitting this option has no effect.

互換性レベルが 100 (SQL Server 2008SQL Server 2008) 以上の場合、インデックス付きビュー、XML インデックス、空間インデックス (存在する場合) について、論理的な一貫性をチェックします。If the compatibility level is 100 ( SQL Server 2008SQL Server 2008) or higher, performs logical consistency checks on an indexed view, XML indexes, and spatial indexes, where present.
詳細については、このトピックの「解説」の「インデックスに対する論理的な一貫性チェックの実行」を参照してください。For more information, see Performing Logical Consistency Checks on Indexes in the Remarks section later in this topic.

すべての情報メッセージを表示しないようにします。Suppresses all informational messages.

DBCC CHECKTABLE が、内部データベースのスナップショットを使用するのではなく、共有テーブル ロックを取得します。Causes DBCC CHECKTABLE to obtain a shared table lock instead of using an internal database snapshot. TABLOCK の作用によって負荷の高いテーブルでも DBCC CHECKTABLE の実行速度が速くなりますが、DBCC CHECKTABLE の実行中はテーブルでのコンカレンシーが低下します。TABLOCK will cause DBCC CHECKTABLE to run faster on a table under heavy load, but decreases the concurrency available on the table while DBCC CHECKTABLE is running.

必要な他のオプションをすべて指定した状態で、DBCC CHECKTABLE の実行時に必要となる tempdb 領域の予測サイズを表示します。Displays the estimated amount of tempdb space needed to run DBCC CHECKTABLE with all the other specified options.

チェック内容を、ページ、レコード ヘッダー、および B ツリーの物理構造の整合性に限定します。Limits the checking to the integrity of the physical structure of the page, record headers and the physical structure of B-trees. テーブルの物理的一貫性に関する低オーバーヘッド チェックを提供するように設計されているため、このチェックではデータが損傷する可能性のある破損ページおよび一般的なハードウェア障害も検出できます。Designed to provide a small overhead check of the physical consistency of the table, this check can also detect torn pages, and common hardware failures that can compromise data. 完全な DBCC CHECKTABLE を実行すると、以前のバージョンよりはるかに時間がかかることがあります。A full run of DBCC CHECKTABLE may take considerably longer than in earlier versions. この現象は次の原因により発生します。This behavior occurs because of the following reasons:

  • 論理チェックの対象範囲が広がった。The logical checks are more comprehensive.
  • チェック対象の、基になる構造の一部が複雑になった。Some of the underlying structures to be checked are more complex.
  • 新機能を含めるために多数の新しいチェックが導入された。Many new checks have been introduced to include the new features.

したがって、大規模なテーブルでは、PHYSICAL_ONLY オプションを使用すると DBCC CHECKTABLE の実行時間が大幅に短縮されることがあるため、実稼働システムで頻繁に使用する場合はこのオプションを使用することをお勧めします。Therefore, using the PHYSICAL_ONLY option may cause a much shorter run-time for DBCC CHECKTABLE on large tables and is therefore recommended for frequent use on production systems. ただし、完全な DBCC CHECKTABLE を定期的に実行することもお勧めします。We still recommend that a full run of DBCC CHECKTABLE be performed periodically. 実行する頻度は、それぞれの業務環境や運用環境に固有の要因によって異なります。The frequency of these runs depends on factors specific to individual businesses and production environments. PHYSICAL_ONLY を指定した場合は常に NO_INFOMSGS も暗黙的に指定されるため、修復オプションを同時指定することはできません。PHYSICAL_ONLY always implies NO_INFOMSGS and is not allowed with any one of the repair options.


PHYSICAL_ONLY を指定すると、DBCC CHECKTABLE で FILESTREAM データのチェックがすべてスキップされるようになります。Specifying PHYSICAL_ONLY causes DBCC CHECKTABLE to skip all checks of FILESTREAM data.

DBCC CHECKTABLE によって、テーブル内に無効な列値または範囲外の列値が含まれていないかチェックされます。Causes DBCC CHECKTABLE to check the table for column values that are not valid or out-of-range. たとえば、datetime 型の場合は、許容範囲外の日時値を含む列が検出されます。decimal 型や概数型の場合は、小数点以下桁数または有効桁数の値が有効ではない列が検出されます。For example, DBCC CHECKTABLE detects columns with date and time values that are larger than or less than the acceptable range for the datetime data type; or decimal or approximate-numeric data type columns with scale or precision values that are not valid.
列の値の整合性チェックは既定で有効になっているため、DATA_PURITY オプションを指定する必要はありません。Column-value integrity checks are enabled by default and do not require the DATA_PURITY option. 以前のバージョンの SQL ServerSQL Server からアップグレードしたデータベースでは、DBCC CHECKTABLE WITH DATA_PURITY を使用して、特定のテーブルのエラーを検出して修正できます。ただし、既定では、テーブルの列値チェックが有効になっていません。データベースに対して DBCC CHECKDB WITH DATA_PURITY を実行し、処理が正常に完了すると、For databases upgraded from earlier versions of SQL ServerSQL Server, you can use DBCC CHECKTABLE WITH DATA_PURITY to find and correct errors on a specific table; however, column-value checks on the table are not enabled by default until DBCC CHECKDB WITH DATA_PURITY has been run error free on the database. DBCC CHECKDB および DBCC CHECKTABLE によって、列値の整合性が既定でチェックされるようになります。After this, DBCC CHECKDB and DBCC CHECKTABLE check column-value integrity by default.
DBCC 修復オプションを使用して、このオプションによって報告された検証エラーを修正することはできません。Validation errors reported by this option cannot be fixed by using DBCC repair options. これらのエラーを手動で修正する方法の詳細については、次のサポート技術情報の資料 923247 を参照してください。SQL Server 2005 以降のバージョンでの DBCC エラー 2570 のトラブルシューティングFor information about manually correcting these errors, see Knowledge Base article 923247: Troubleshooting DBCC error 2570 in SQL Server 2005 and later versions.
PHYSICAL_ONLY を指定した場合は、列の整合性チェックは行われません。If PHYSICAL_ONLY is specified, column-integrity checks are not performed.

適用対象:SQL ServerSQL Server (SQL Server 2014 (12.x)SQL Server 2014 (12.x) SP2 から SQL Server 2017SQL Server 2017)。Applies to: SQL ServerSQL Server (Starting with SQL Server 2014 (12.x)SQL Server 2014 (12.x) SP2 through SQL Server 2017SQL Server 2017).

ステートメントの sp_configuremax degree of parallelism 構成オプションをオーバーライドします。Overrides the max degree of parallelism configuration option of sp_configure for the statement. MAXDOP では、sp_configure で構成されている値を超えることができます。The MAXDOP can exceed the value configured with sp_configure. MAXDOP では、Resource Governor で構成されている値を超えると、データベース エンジンは、「ALTER WORKLOAD GROUP (TRANSACT-SQL)」に記載のリソース ガバナーの MAXDOP 値を使用します。If MAXDOP exceeds the value configured with Resource Governor, the Database Engine uses the Resource Governor MAXDOP value, described in ALTER WORKLOAD GROUP (Transact-SQL). MAXDOP クエリ ヒントを使用している場合は、max degree of parallelism 構成オプションで使用されるすべての意味ルールを適用できます。All semantic rules used with the max degree of parallelism configuration option are applicable when you use the MAXDOP query hint. 詳細については、「 max degree of parallelism サーバー構成オプションの構成」を参照してください。For more information, see Configure the max degree of parallelism Server Configuration Option.


MAXDOP が 0 に設定されている場合、サーバーでは最大限の並列処理が実行されます。If MAXDOP is set to zero then the server chooses the max degree of parallelism.



データベース内のすべてのテーブルに対して DBCC CHECKTABLE を実行するには、DBCC CHECKDB を使用します。To perform DBCC CHECKTABLE on every table in the database, use DBCC CHECKDB.

指定したテーブルについて、DBCC CHECKTABLE によって次の項目がチェックされます。For the specified table, DBCC CHECKTABLE checks for the following:

  • インデックス、行内、LOB、および行オーバーフロー データの各ページが正しくリンクされていること。Index, in-row, LOB, and row-overflow data pages are correctly linked.
  • インデックスが正しい並べ替え順序で並んでいること。Indexes are in their correct sort order.
  • ポインターに一貫性があること。Pointers are consistent.
  • 各ページ上のデータが、計算列も含め、適切であること。The data on each page is reasonable, included computed columns.
  • ページ オフセットが適切であること。Page offsets are reasonable.
  • ベース テーブルと各非クラスター化インデックスのすべての行がそれぞれに対応していること。Every row in the base table has a matching row in each nonclustered index, and vice-versa.
  • パーティション テーブルやパーティション インデックスのすべての行が正しいパーティションにあること。Every row in a partitioned table or index is in the correct partition.
  • FILESTREAM を使用して varbinary(max) データをファイル システムに格納する場合のファイル システムとテーブル間でのリンクレベルの一貫性。Link-level consistency between the file system and table when storing varbinary(max) data in the file system using FILESTREAM.

インデックスに対する論理的な一貫性チェックの実行Performing Logical Consistency Checks on Indexes

インデックスに対する論理的な一貫性チェックは、データベースの互換性レベルによって次のように異なります。Logical consistency checking on indexes varies according to the compatibility level of the database, as follows:

  • 互換性レベルが 100 (SQL Server 2008SQL Server 2008) 以上の場合:If the compatibility level is 100 (SQL Server 2008SQL Server 2008) or higher:

    • NOINDEX が指定されていない場合、DBCC CHECKTABLE は、1 つのテーブルとそのすべての非クラスター化インデックスについて、物理的な一貫性と論理的な一貫性の両方をチェックします。Unless NOINDEX is specified, DBCC CHECKTABLE performs both physical and logical consistency checks on a single table and on all its nonclustered indexes. ただし、XML インデックス、空間インデックス、およびインデックス付きビューでは、既定で物理的な一貫性のみがチェックされます。However, on XML indexes, spatial indexes, and indexed views only physical consistency checks are performed by default.
    • WITH EXTENDED_LOGICAL_CHECKS が指定されている場合、インデックス付きビュー、XML インデックス、および空間インデックス (存在する場合) に対して論理チェックが実行されます。If WITH EXTENDED_LOGICAL_CHECKS is specified, logical checks are performed on an indexed view, XML indexes, and spatial indexes, where present. 既定では、論理的な一貫性のチェック前に物理的な一貫性がチェックされます。By default, physical consistency checks are performed before the logical consistency checks. NOINDEX も指定されている場合は、論理チェックのみが実行されます。If NOINDEX is also specified, only the logical checks are performed.
      この論理的な一貫性のチェックでは、インデックス オブジェクトの内部インデックス テーブルが参照先のユーザー テーブルと照合されます。These logical consistency checks cross check the internal index table of the index object with the user table that it is referencing. 行の不整合を検出するために、内部テーブルとユーザー テーブルの完全な積集合を実行する内部クエリが作成されます。To find outlying rows, an internal query is constructed to perform a full intersection of the internal and user tables. このクエリを実行するとパフォーマンスに多大な影響を及ぼす可能性があり、その進行状況は追跡できません。Running this query can have a very high effect on performance, and its progress cannot be tracked. したがって、物理的な破損とは無関係のインデックスの問題があると考えられる場合、またはページ レベルのチェックサムがオフになっており、列レベルのハードウェアの破損が考えられる場合にのみ、WITH EXTENDED_LOGICAL_CHECKS を指定することをお勧めします。Therefore, we recommend that you specify WITH EXTENDED_LOGICAL_CHECKS only if you suspect index issues that are unrelated to physical corruption, or if page-level checksums have been turned off and you suspect column-level hardware corruption.
    • インデックスがフィルター選択されたインデックスである場合、DBCC CHECKDB は一貫性チェックを実行して、インデックス エントリがフィルター述語に適合していることを確認します。If the index is a filtered index, DBCC CHECKDB performs consistency checks to verify that the index entries satisfy the filter predicate.
  • SQL Server 2016 (13.x)SQL Server 2016 (13.x) 以降では、コストの高い式の評価を避けるため、既定では、保存される計算列、UDT 列、およびフィルター選択されたインデックスへの追加のチェックは実行されません。Starting with SQL Server 2016 (13.x)SQL Server 2016 (13.x), additional checks on persisted computed columns, UDT columns, and filtered indexes will not run by default to avoid the expensive expression evaluations. この変更により、これらのオブジェクトを含むデータベースに対する CHECKDB の時間が大幅に短縮されます。This change greatly reduces the duration of CHECKDB against databases containing these objects. ただし、これらのオブジェクトの物理的な整合性チェックは常に実行されます。However, the physical consistency checks of these objects is always completed. EXTENDED_LOGICAL_CHECKS オプションが指定されている場合にのみ、既存の論理チェック (インデックス付きビュー、XML インデックス、および空間インデックス) に加え、EXTENDED_LOGICAL_CHECKS オプションの一部として式の評価が行われます。Only when EXTENDED_LOGICAL_CHECKS option is specified will the expression evaluations be performed in addition to already present logical checks (indexed view, XML indexes, and spatial indexes) as part of the EXTENDED_LOGICAL_CHECKS option.

  • 互換性レベルが 90 (SQL Server 2005 (9.x)SQL Server 2005 (9.x)) 以下で NOINDEX が指定されていない場合、DBCC CHECKTABLE は、1 つのテーブルまたはインデックス付きビューと、そのすべての非クラスター化インデックスおよび XML インデックスについて、物理的な一貫性と論理的な一貫性の両方をチェックします。If the compatibility level is 90 (SQL Server 2005 (9.x)SQL Server 2005 (9.x)) or less, unless NOINDEX is specified, DBCC CHECKTABLE performs both physical and logical consistency checks on a single table or indexed view and on all its nonclustered and XML indexes. 空間インデックスはサポートされません。Spatial indexes are not supported.

データベースの互換性レベルを調べるには To learn the compatibility level of a database
データベースの互換性レベルの表示または変更View or Change the Compatibility Level of a Database

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

DBCC CHECKTABLE は、内部データベースのスナップショットを使用して、これらのチェックを実行するために必要なトランザクションの一貫性を確保します。DBCC CHECKTABLE uses an internal database snapshot to provide the transactional consistency that it must have to perform these checks. 詳細については、次を参照してください。「データベース スナップショットのスパース ファイルのサイズを表示する方法 (Transact-SQL)」および「DBCC (Transact-SQL)」の「DBCC 内部データベース スナップショットの使用」セクション。For more information, see View the Size of the Sparse File of a Database Snapshot (Transact-SQL) and the "DBCC Internal Database Snapshot Usage" section in DBCC (Transact-SQL). スナップショットを作成できない場合や、TABLOCK が指定されている場合は、DBCC CHECKTABLE は共有テーブル ロックを取得して必要な一貫性を実現します。If a snapshot cannot be created, or TABLOCK is specified, DBCC CHECKTABLE acquires a shared table lock to obtain the required consistency.


tempdb に対して DBCC CHECKTABLE を実行する場合、共有テーブル ロックを取得する必要があります。If DBCC CHECKTABLE is run against tempdb, it must acquire a shared table lock. これは、パフォーマンス上の理由から、データベースのスナップショットが tempdb では利用できないためです。This is because, for performance reasons, database snapshots are not available on tempdb. つまり、必要なトランザクションの一貫性を実現できないためです。This means that the required transactional consistency cannot be obtained.

FILESTREAM データのチェックと修復Checking and Repairing FILESTREAM Data

データベースとテーブルに対して FILESTREAM が有効になっている場合、varbinary(max) バイナリ ラージ オブジェクト (BLOB) をファイル システムに格納することもできます。When FILESTREAM is enabled for a database and table, you can optionally store varbinary(max) binary large objects (BLOBs) in the file system. BLOB をファイル システムに格納するテーブルに対して DBCC CHECKTABLE を使用する場合は、DBCC によって、ファイル システムとデータベースの間でのリンクレベルの一貫性がチェックされます。When using DBCC CHECKTABLE on a table that stores BLOBs in the file system, DBCC checks link-level consistency between the file system and database. たとえば、テーブルに FILESTREAM 属性を使用する varbinary(max) 列が含まれている場合、DBCC CHECKTABLE は、ファイル システムのディレクトリおよびファイルと、テーブルの行、列、および列の値とが一対一でマップされていることをチェックします。For example, if a table contains a varbinary(max) column that uses the FILESTREAM attribute, DBCC CHECKTABLE will check that there is a one-to-one mapping between file system directories and files and table rows, columns, and column values. REPAIR_ALLOW_DATA_LOSS オプションを指定すると、DBCC CHECKTABLE で破損を修復できます。DBCC CHECKTABLE can repair corruption if you specify the REPAIR_ALLOW_DATA_LOSS option. FILESTREAM の破損を修復するため、DBCC はファイル システム データがないテーブル行をすべて削除し、テーブルの行、列、および列の値にマップされないディレクトリとファイルをすべて削除します。To repair FILESTREAM corruption, DBCC will delete any table rows that are missing file system data and will delete any directories and files that do not map to a table row, column, or column value.

オブジェクトの並列チェックChecking Objects in Parallel

既定では、DBCC CHECKTABLE はオブジェクトの並列チェックを実行します。By default, DBCC CHECKTABLE performs parallel checking of objects. 並列処理の次数は、クエリ プロセッサによって自動的に決定されます。The degree of parallelism is automatically determined by the query processor. 並列処理の最大限度は、並列クエリと同様に構成します。The maximum degree of parallelism is configured in the same manner as that of parallel queries. DBCC チェックに利用できるプロセッサの最大数を制限するには、sp_configure を使用します。To restrict the maximum number of processors available for DBCC checking, use sp_configure. 詳細については、「 max degree of parallelism サーバー構成オプションの構成」を参照してください。For more information, see Configure the max degree of parallelism Server Configuration Option. 並列チェックはトレース フラグ 2528 を使用して無効にできます。Parallel checking can be disabled by using trace flag 2528. 詳細については、「トレース フラグ (Transact-SQL)」を参照してください。For more information, see Trace Flags (Transact-SQL).


DBCC CHECKTABLE の操作中、バイト順のユーザー定義型の列に保存されるバイトは、シリアル化されたユーザー定義型の計算値と同じである必要があります。During a DBCC CHECKTABLE operation, the bytes that are stored in a byte-ordered user-defined type column must be equal to the computed serialization of the user-defined type value. 同じでない場合は、DBCC CHECKTABLE ルーチンで一貫性エラーが報告されます。If this is not true, the DBCC CHECKTABLE routine will report a consistency error.

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

DBCC CHECKTABLE コマンドの終了後、メッセージが SQL ServerSQL Server エラー ログに書き込まれます。After the DBCC CHECKTABLE command finishes, a message is written to the SQL ServerSQL Server error log. DBCC コマンドが正常に実行された場合、メッセージでは正常完了とコマンド実行時間が示されます。If the DBCC command successfully executes, the message indicates a successful completion and the amount of time that the command ran. エラーが発生して DBCC コマンドが完了前に停止した場合、メッセージではコマンドが終了したことと、状態の値、コマンド実行時間が示されます。If the DBCC command stops before completing the check because of an error, the message indicates the command was terminated, a state value, and the amount of time the command ran. 次の表は、メッセージに含まれる可能性がある状態値の一覧と説明です。The following table lists and describes the state values that can be included in the message.

状態State [説明]Description
00 エラー番号 8930 が発生しました。Error number 8930 was raised. メタデータの破損が原因で DBCC コマンドが終了しました。This indicates a metadata corruption that caused the DBCC command to terminate.
11 エラー番号 8967 が発生しました。Error number 8967 was raised. 内部 DBCC エラーがあります。There was an internal DBCC error.
22 緊急モードのデータベース修復中にエラーが発生しました。A failure occurred during emergency mode database repair.
33 メタデータの破損が原因で DBCC コマンドが終了しました。This indicates a metadata corruption that caused the DBCC command to terminate.
44 アサートまたはアクセス違反が検出されました。An assert or access violation was detected.
55 不明なエラーが発生し、DBCC コマンドが終了しました。An unknown error occurred that terminated the DBCC command.

[エラー報告]Error Reporting

DBCC CHECKTABLE により破損エラーが検出されるたびに、ミニ ダンプ ファイル (SQLDUMP*nnnn*.txt) が SQL ServerSQL Server の LOG ディレクトリに生成されます。A mini-dump file (SQLDUMP*nnnn*.txt) is created in the SQL ServerSQL Server LOG directory whenever DBCC CHECKTABLE detects a corruption error. 機能の使用状況データ収集とエラー報告機能が SQL ServerSQL Server インスタンスに対して有効になっている場合、ダンプ ファイルは自動的に MicrosoftMicrosoft に転送されます。When the Feature Usage data collection and Error Reporting features are enabled for the instance of SQL ServerSQL Server, the file is automatically forwarded to MicrosoftMicrosoft. 収集されたデータは SQL ServerSQL Server の機能向上のために使用されます。The collected data is used to improve SQL ServerSQL Server functionality. このダンプ ファイルには、DBCC CHECKTABLE コマンドの結果と追加の診断出力が含まれます。The dump file contains the results of the DBCC CHECKTABLE command and additional diagnostic output. また、制限付きの随意アクセス制御リスト (DACL) が割り当てられます。The file has restricted discretionary access-control lists (DACLs). アクセスが、SQL ServerSQL Server サービス アカウントと sysadmin ロールのメンバーに制限されます。Access is limited to the SQL ServerSQL Server service account and members of the sysadmin role. 既定では、sysadmin ロールには、Windows の builtin \administrators グループとローカルの管理者のグループのすべてのメンバーが含まれています。By default, the sysadmin role contains all members of the Windows BUILTIN\Administrators group and the local administrator's group. データ収集プロセスが失敗しても、DBCC コマンドは失敗しません。The DBCC command does not fail if the data collection process fails.

エラーの解決Resolving Errors

DBCC CHECKTABLE でエラーが報告された場合は、REPAIR オプションのいずれかを指定して実行するのではなく、データベースのバックアップからデータベースを復元することをお勧めします。If DBCC CHECKTABLE reports any errors, we recommend restoring the database from the database backup instead of running REPAIR with one of the REPAIR options. バックアップが存在しない場合は、REPAIR を実行することによって、報告されたエラーを修正できます。If no backup exists, running REPAIR can correct the errors that are reported. 使用する REPAIR オプションは、報告されたエラーの一覧の最後に指定されています。The REPAIR option to use is specified at the end of the list of reported errors. ただし、REPAIR_ALLOW_DATA_LOSS オプションを使用してエラーを修正する場合は、一部のページ (データ) が削除されることがあります。However, that correcting the errors by using the REPAIR_ALLOW_DATA_LOSS option might require that some pages, and therefore data, be deleted.
ユーザー トランザクションを利用して修復を実行できるので、後からユーザーが変更をロールバックすることができます。The repair can be performed under a user transaction to allow the user to roll back the changes that have been made. 修復をロールバックしたときは、データベースにエラーが残っているので、データベースをバックアップから復元する必要があります。If repairs are rolled back, the database will still contain errors and must be restored from a backup. すべての修復が完了したら、データベースをバックアップします。After you have completed all repairs, back up the database.

結果セットResult Sets

DBCC CHECKTABLE は次の結果セットを返します。DBCC CHECKTABLE returns the following result set. テーブル名のみを指定した場合もその他のオプションを指定した場合も、同じ結果セットを返します。The same result set is returned if you specify only the table name or any of the options.

DBCC results for 'HumanResources.Employee'.    
There are 288 rows in 13 pages for object 'Employee'.    
DBCC execution completed. If DBCC printed error messages, contact your system administrator.    

ESTIMATEONLY オプションを指定した場合、DBCC CHECKTABLE は次の結果セットを返します。DBCC CHECKTABLE returns the following result set if the ESTIMATEONLY option is specified:

Estimated TEMPDB space needed for CHECKTABLES (KB)     
(1 row(s) affected)    
DBCC execution completed. If DBCC printed error messages, contact your system administrator.    


ユーザーは、テーブルを所有しているか、sysadmin 固定サーバー ロール、db_owner 固定サーバー ロール、または db_ddladmin 固定データベース ロールのメンバーである必要があります。User must own the table, or be a member of the sysadmin fixed server role, the db_owner fixed database role, or the db_ddladmin fixed database role.


A.A. 特定のテーブルをチェックするChecking a specific table

次の例では、AdventureWorks2012AdventureWorks2012 データベースにある HumanResources.Employee テーブルのデータ ページの整合性をチェックします。The following example checks the data page integrity of the HumanResources.Employee table in the AdventureWorks2012AdventureWorks2012 database.

DBCC CHECKTABLE ('HumanResources.Employee');    

B.B. テーブルの低オーバーヘッド チェックを実行するPerforming a low-overhead check of the table

次の例では、AdventureWorks2012AdventureWorks2012 データベースにある Employee テーブルの低オーバーヘッド チェックを実行します。The following example performs a low overhead check of the Employee table in the AdventureWorks2012AdventureWorks2012 database.

DBCC CHECKTABLE ('HumanResources.Employee') WITH PHYSICAL_ONLY;    

C.C. 特定のインデックスをチェックするChecking a specific index

次の例では、sys.indexes にアクセスすることによって取得される特定のインデックスをチェックします。The following example checks a specific index, obtained by accessing sys.indexes.

DECLARE @indid int;    
SET @indid = (SELECT index_id     
              FROM sys.indexes    
              WHERE object_id = OBJECT_ID('Production.Product')    
                    AND name = 'AK_Product_Name');    
DBCC CHECKTABLE ('Production.Product',@indid);    

参照See Also

DBCC (Transact-SQL) DBCC (Transact-SQL)