適用対象:○SQL Server (2012 以降)○Azure SQL DatabaseXAzure SQL Data Warehouse XParallel Data Warehouse THIS TOPIC APPLIES TO:yesSQL Server (starting with 2012)yesAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

次の操作を実行し、指定したデータベース内のすべてのオブジェクトの論理的および物理的な整合性をチェックします。Checks the logical and physical integrity of all the objects in the specified database by performing the following operations:

注:メモリ最適化テーブルを含むデータベースで DBCC CHECKDB がサポートされていますが、検証は、ディスク ベース テーブルでのみ行われます。NOTE: DBCC CHECKDB is supported on databases that contain memory-optimized tables but validation only occurs on disk-based tables. ただし、データベースのバックアップおよび復旧の一環として、メモリ最適化ファイル グループ内のファイルに対してチェックサム検証が実行されます。However, as part of database backup and recovery, a CHECKSUM validation is done for files in memory-optimized filegroups.

DBCC 修復オプションはメモリ最適化テーブルに使用できないため、データベースを定期的にバックアップし、バックアップをテストする必要があります。Since DBCC repair options are not available for memory-optimized tables, you must back up your databases regularly and test the backups. メモリ最適化テーブルでデータ整合性の問題が発生した場合は、最新の既知の良好なバックアップから復元する必要があります。If data integrity issues occur in a memory-optimized table, you must restore from the last known good backup.

  • 実行DBCC CHECKALLOCデータベースでします。Runs DBCC CHECKALLOC on the database.

  • 実行DBCC CHECKTABLEすべてのテーブルと、データベースのビューです。Runs DBCC CHECKTABLE on every table and view in the database.

  • 実行DBCC CHECKCATALOGデータベースでします。Runs DBCC CHECKCATALOG on the database.

  • データベース内にあるすべてのインデックス付きビューの内容を検証。Validates the contents of every indexed view in the database.

  • 格納する場合テーブル メタデータとファイル システムのディレクトリとファイルの間のリンクレベルの一貫性を検証varbinary (max) FILESTREAM を使用して、ファイル システム内のデータ。Validates link-level consistency between table metadata and file system directories and files when storing varbinary(max) data in the file system using FILESTREAM.

  • 検証、 Service BrokerService Brokerデータベース内のデータ。Validates the Service BrokerService Broker data in the database.

    DBCC CHECKALLOC、DBCC CHECKTABLE、または DBCC CHECKCATALOG コマンドは、DBCC CHECKDB と別に実行する必要はありません。This means that the DBCC CHECKALLOC, DBCC CHECKTABLE, or DBCC CHECKCATALOG commands do not have to be run separately from DBCC CHECKDB. これらのコマンドで実行されるチェックに関する詳細については、各コマンドの説明を参照してください。For more detailed information about the checks that these commands perform, see the descriptions of these commands.

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


    [ ( database_name | database_id | 0    
        [ , NOINDEX     
    ) ]    
    [ WITH     
            [ ALL_ERRORMSGS ]    
            [ , EXTENDED_LOGICAL_CHECKS ]     
            [ , NO_INFOMSGS ]    
            [ , TABLOCK ]    
            [ , ESTIMATEONLY ]    
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]    
            [ , MAXDOP  = number_of_processors ]    


database_name | database_id | 0database_name | database_id | 0
整合性チェックを実行するデータベースの名前または ID です。Is the name or ID of the database for which to run integrity checks. 値を指定しないか 0 を指定した場合は、現在のデータベースが使用されます。If not specified, or if 0 is specified, the current database is used. データベース名は、規則に従う必要があります識別子です。Database 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 integrity checks are always performed on system table indexes.

検出されたエラーを DBCC CHECKDB が修復するように指定します。Specifies that DBCC CHECKDB repair the found errors. REPAIR オプションは、最後の手段としてのみ使用してください。Use the REPAIR options only as a last resort. 修復オプションを使用するには、指定するデータベースがシングル ユーザー モードになっている必要があります。以下の修復オプションを使用できます。The specified database must be in single-user mode to use one of the following repair options.

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

  • REPAIR_ALLOW_DATA_LOSS オプションはサポートされている機能いる可能性がありますいない常に物理的に一貫性のある状態にデータベースを取り込むに最適なオプションです。The REPAIR_ALLOW_DATA_LOSS option is a supported feature but it may not always be the best option for bringing a database to a physically consistent state. -成功した場合、REPAIR_ALLOW_DATA_LOSS オプションによってデータが失われる可能性があります。-If successful, the REPAIR_ALLOW_DATA_LOSS option may result in some data loss. 実際には、ユーザーが最後の既知の良好なバックアップからデータベースを復元する場合よりも、失われるデータが多い場合があります。In fact, it may result in more data lost than if a user were to restore the database from the last known good backup.

  • MicrosoftMicrosoft では、DBCC CHECKDB によって報告されたエラーから回復する主要な方法として、ユーザーが最後の既知の良好なバックアップから復元することが常に推奨されています。 always recommends a user restore from the last known good backup as the primary method to recover from errors reported by DBCC CHECKDB. REPAIR_ALLOW_DATA_LOSS オプションは、既知の適切なバックアップから復元する代替手段ではありません。The REPAIR_ALLOW_DATA_LOSS option is not an alternative for restoring from a known good backup. これは、緊急時の「最後の手段」のオプションで、バックアップからの復元ができない場合にのみ使用することをお勧めします。It is an emergency “last resort” option recommended for use only if restoring from a backup is not possible.

    • REPAIR_ALLOW_DATA_LOSS オプションを使用してのみ修復できる特定のエラーには、エラーを消去するための行、ページ、または一連のページの割り当ての解除が含まれます。Certain errors, that can only be repaired using the REPAIR_ALLOW_DATA_LOSS option, may involve deallocating a row, page, or series of pages to clear the errors. 割り当てが解除されたデータは、ユーザーがアクセスできなくなり、回復が不可能になり、割り当てが解除されたデータの内容を正確に特定できません。Any deallocated data is no longer accessible or recoverable for the user, and the exact contents of the deallocated data cannot be determined. このため、任意の行またはページの割り当てが解除されると、この修復操作の一部として外部キー制約がチェックまたは保守されないため、参照整合性が正確でない可能性があります。Therefore, referential integrity may not be accurate after any rows or pages are deallocated because foreign key constraints are not checked or maintained as part of this repair operation. ユーザーは、REPAIR_ALLOW_DATA_LOSS オプションを使用した後で、(DBCC CHECKCONSTRAINTS を使用して)、データベースの参照整合性を調べる必要があります。The user must inspect the referential integrity of their database (using DBCC CHECKCONSTRAINTS) after using the REPAIR_ALLOW_DATA_LOSS option.

    • 修復を実行する前に、このデータベースに属しているファイルの物理コピーを作成します。Before performing the repair, create physical copies of the files that belong to this database. これには、プライマリ データ ファイル (.mdf)、すべてのセカンダリ データ ファイル (.ndf)、すべてのトランザクション ログ ファイル (.ldf)、およびフルテキスト カタログ、ファイル ストリームのフォルダー、メモリ最適化データなどを含むデータベースを形成する他のコンテナーが含まれます。This includes the primary data file (.mdf), any secondary data files (.ndf), all transaction log files (.ldf), and other containers that form the database including full text catalogs, file stream folders, memory optimized data, etc.

    • 修復を実行する前に、データベースの状態を EMERGENCY モードに変更し、クリティカルなテーブルから可能な限り多くの情報を抽出してデータを保存することを検討してください。Before performing the repair, consider changing the state of the database to EMERGENCY mode and trying to extract as much information possible from the critical tables and save that data.

旧バージョンとの互換性のためにのみ、構文が用意されています。Maintains syntax 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 non-clustered indexes, and more time-consuming repairs, such as rebuilding an index.
この引数では、FILESTREAM データに関係するエラーは修復されません。This argument does not repair errors involving FILESTREAM data.


任意の REPAIR オプションが指定された DBCC CHECKDB は、完全にログに記録されて回復可能なため、 MicrosoftMicrosoft は常にユーザーがトランザクション内で REPAIR オプションを使用して CHECKDB を使用することをお勧めします (コマンドを実行する前に、BEGIN TRANSACTION を実行します)。これにより、ユーザーが操作の結果を受け入れるか確認することができます。Since DBCC CHECKDB with any of the REPAIR options are completely logged and recoverable, MicrosoftMicrosoft always recommends a user use CHECKDB with any REPAIR options within a transaction (execute BEGIN TRANSACTION before running the command) so that the user can confirm he/she wants to accept the results of the operation. ユーザーは、COMMIT TRANSACTION を実行して、修復操作によってなされたすべての作業をコミットできます。Then the user can execute COMMIT TRANSACTION to commit all work done by the repair operation. ユーザーが操作の結果を受け入れない場合は、ROLLBACK TRANSACTION を実行して、修復操作の結果を元に戻すことができます。If the user does not want to accept the results of the operation, he/she can execute a ROLLBACK TRANSACTION to undo the effects of the repair operations.

エラーの修復では、バックアップから復元することをお勧めします。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 CHECKDB を実行して、使用する修復レベルを確認してください。If you must use REPAIR, run DBCC CHECKDB without a repair option to find the repair level to use. REPAIR_ALLOW_DATA_LOSS レベルを使用する場合は、このオプションを指定して DBCC CHECKDB を実行する前に、データベースをバックアップすることをお勧めします。If you use the REPAIR_ALLOW_DATA_LOSS level, we recommend that you back up the database before you run DBCC CHECKDB with this option.

オブジェクトごとに、報告されているすべてのエラーを表示します。Displays all reported errors per object. 既定では、すべてのエラー メッセージが表示されます。All error messages are displayed by default. そのため、このオプションを指定しても省略しても影響はありません。Specifying or omitting this option has no effect. エラー メッセージはから生成されるメッセージを除き、オブジェクト ID で並べ替えられますtempdb データベースです。Error messages are sorted by object ID, except for those messages generated from tempdb database.


SQL Server Management StudioSQL Server Management Studio では、返されるエラー メッセージの最大数は 1000 です。In SQL Server Management StudioSQL Server Management Studio, the maximum number of error messages returned is 1000. 使用して、DBCC コマンドを実行することをお勧め ALL_ERRORMSGS を指定すると、 sqlcmd ユーティリティまたはスケジュールすることによって、 SQL ServerSQL Serverコマンドを実行し、ファイルに出力するエージェント ジョブ。When you specify ALL_ERRORMSGS, we recommend that you run the DBCC command by using the sqlcmd utility or by scheduling a SQL ServerSQL Server Agent job to run the command and direct the output to a file. どちらの方法でも、コマンドを 1 回実行するとすべてのエラー メッセージが出力されます。Either of these methods will ensure that running the command once will report all error messages.

互換性レベルが 100 の場合 ( SQL Server 2008:SQL Server 2008) または存在する場合、以降では、インデックス付きビュー、XML インデックス、および空間インデックスは、論理的な一貫性チェックを実行します。If the compatibility level is 100 ( SQL Server 2008:SQL 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 CHECKDB が、内部データベースのスナップショットを使用せずに、ロックを取得します。Causes DBCC CHECKDB to obtain locks instead of using an internal database snapshot. これにはデータベースの短期の排他 (X) ロックも含まれます。This includes a short-term exclusive (X) lock on the database. TABLOCK の作用によって負荷の高いデータベースでも DBCC CHECKDB の実行速度が速くなりますが、DBCC CHECKDB の実行中はデータベースでの同時実行性が低下します。TABLOCK will cause DBCC CHECKDB to run faster on a database under heavy load, but decreases the concurrency available on the database while DBCC CHECKDB is running.


TABLOCK では実行されるチェックが制限されます。DBCC CHECKCATALOG はデータベースに対して実行されず、 Service BrokerService Broker データは検証されません。TABLOCK limits the checks that are performed; DBCC CHECKCATALOG is not run on the database, and Service BrokerService Broker data is not validated.

その他のすべての指定したオプションで DBCC CHECKDB を実行するために必要な tempdb 領域の推定サイズが表示されます。Displays the estimated amount of tempdb space that is required to run DBCC CHECKDB with all the other specified options. 実際のデータベースのチェックは行われません。The actual database check is not performed.

チェック内容を、ページとレコード ヘッダーの物理構造の整合性、およびデータベースの割り当ての一貫性に限定します。Limits the checking to the integrity of the physical structure of the page and record headers and the allocation consistency of the database. このチェックは、データベースの物理的一貫性に関する低オーバーヘッド チェックを提供するように設計されているため、ユーザーのデータが損傷する可能性のある破損ページやチェックサム エラー、および一般的なハードウェア障害も検出できます。This check is designed to provide a small overhead check of the physical consistency of the database, but it can also detect torn pages, checksum failures, and common hardware failures that can compromise a user's data.
完全な DBCC CHECKDB を実行すると、完了するまでに以前のバージョンよりはるかに時間がかかることがあります。A full run of DBCC CHECKDB may take considerably longer to complete than earlier versions. この動作は、ために発生します。This behavior occurs because:

  • 論理チェックの対象範囲が広がった。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 CHECKDB の実行時間が大幅に短縮されることがあるため、実稼働システムで頻繁に使用する場合はこのオプションを使用することをお勧めします。Therefore, using the PHYSICAL_ONLY option may cause a much shorter run-time for DBCC CHECKDB on large databases and is recommended for frequent use on production systems. ただし、完全な DBCC CHECKDB を定期的に実行することもお勧めします。We still recommend that a full run of DBCC CHECKDB be performed periodically. 実行する頻度は、それぞれの業務環境や運用環境に固有の要因によって異なります。The frequency of these runs depends on factors specific to individual businesses and production environments.
    この argment 常に NO_INFOMSGS を暗黙的には、修復オプションのいずれかでは許可されていません。This argment always implies NO_INFOMSGS and is not allowed with any one of the repair options.

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

DBCC CHECKDB が、データベース内の、値が無効または範囲外の列をチェックします。Causes DBCC CHECKDB to check the database for column values that are not valid or out-of-range. たとえば、DBCC CHECKDB が日付と時刻の値がより大きいか、許容範囲よりも小さいかを含む列を検出、 datetimeデータ型またはdecimal型または概数データ型無効な小数点以下桁数または有効桁数の値を持つ列。For example, DBCC CHECKDB 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 CHECKDB WITH DATA_PURITY で実行されているエラーのないデータベースになるまでに既定で無効になってを確認します。For databases upgraded from earlier versions of SQL ServerSQL Server, column-value checks are not enabled by default until DBCC CHECKDB WITH DATA_PURITY has been run error free on the database. エラーなく実行されると、その後、DBCC CHECKDB は既定で列の値の整合性をチェックします。After this, DBCC CHECKDB checks column-value integrity by default. 以前のバージョンの SQL ServerSQL Server からのデータベースのアップグレードによる CHECKDB への影響の詳細については、後の「解説」を参照してください。For more information about how CHECKDB might be affected by upgrading database from earlier versions of SQL ServerSQL Server, see the Remarks section later in this topic.


PHYSICAL_ONLY を指定した場合は、列の整合性チェックは行われません。If PHYSICAL_ONLY is specified, column-integrity checks are not performed.

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.

適用されます: SQL Server 2014SQL Server 2014を通じて SP2 SQL Server 2017SQL Server 2017です。Applies to: SQL Server 2014SQL Server 2014 SP2 through SQL Server 2017SQL Server 2017.

上書き、並列処理の次数の最大構成オプションのsp_configureステートメントです。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 値を超える場合、リソース ガバナーで構成されている、SQL Server データベース エンジンSQL Server Database Engineで説明されている、リソース ガバナーの MAXDOP 値を使用してALTER WORKLOAD GROUPです。If MAXDOP exceeds the value configured with Resource Governor, the SQL Server データベース エンジンSQL Server Database Engine uses the Resource Governor MAXDOP value, described in ALTER WORKLOAD GROUP. 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 は、SQL Server を 0 に設定されている場合は、使用する並列処理の最大限度を選択します。If MAXDOP is set to zero then SQL Server chooses the max degree of parallelism to use.


DBCC CHECKDB は、無効なインデックスについては検査しません。DBCC CHECKDB does not examine disabled indexes. 無効化されたインデックスの詳細については、次を参照してください。無効にするインデックスと制約です。For more information about disabled indexes, see Disable Indexes and Constraints. ユーザー定義型がバイト順としてマークされている場合、シリアル化されたユーザー定義型は 1 つだけ存在する必要があります。If a user-defined type is marked as being byte ordered, there must only be one serialization of the user-defined type. シリアル化されたバイト順のユーザー定義型が一貫して存在していない場合、DBCC CHECKDB の実行中にエラー 2537 が発生します。Not having a consistent serialization of byte-ordered user-defined types causes error 2537 when DBCC CHECKDB is run. 詳細については、次を参照してください。ユーザー定義型の要件です。For more information, see User-Defined Type Requirements. Resource データベースはシングル ユーザー モードでは、コマンドは、上で直接実行することはできません、DBCC CHECKDB でのみ変更します。Because the Resource database is modifiable only in single-user mode, the DBCC CHECKDB command cannot be run on it directly. ただし、DBCC CHECKDB が実行されるとに対して、 master データベース、Resource データベースで次の CHECKDB が内部的に実行もします。However, when DBCC CHECKDB is executed against the master database, a second CHECKDB is also run internally on the Resource database. このため、DBCC CHECKDB が追加の結果を返す場合があります。This means that DBCC CHECKDB can return extra results. このコマンドでは、オプションが設定されていないか、PHYSICAL_ONLY または ESTIMATEONLY オプションが設定されている場合に、追加の結果セットが返されます。The command returns extra result sets when no options are set, or when either the PHYSICAL_ONLY or ESTIMATEONLY option is set. SP2 より前のバージョンの SQL Server 2005SQL Server 2005 で DBCC CHECKDB を実行すると、 SQL ServerSQL Server インスタンスのプラン キャッシュが消去されます。In versions of SQL Server 2005SQL Server 2005 before SP2, executing DBCC CHECKDB clears the plan cache for the instance of SQL ServerSQL Server. プラン キャッシュをクリアする以降のすべての実行プランの再コンパイルとクエリのパフォーマンス、突然、一時的な低下が発生する可能性があります。Clearing the plan cache causes recompilation of all later execution plans and may cause a sudden, temporary decrease in query performance. SP2 以降では、DBCC CHECKDB を実行してもプラン キャッシュは消去されません。In SP2 and later, executing DBCC CHECKDB does not clear the plan cache.

インデックスに対する論理的な一貫性チェックの実行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 2008:SQL Server 2008) またはそれ以降。If the compatibility level is 100 ( SQL Server 2008:SQL Server 2008) or higher:
  • NOINDEX が指定されていない場合、DBCC CHECKDB は、1 つのテーブルとそのすべての非クラスター化インデックスについて、物理的な一貫性と論理的な一貫性の両方をチェックします。Unless NOINDEX is specified, DBCC CHECKDB 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.
  • 互換性レベルが 90 以下で NOINDEX が指定されていない場合、DBCC CHECKDB は、1 つのテーブルまたはインデックス付きビューと、そのすべての非クラスター化インデックスおよび XML インデックスについて、物理的な一貫性と論理的な一貫性の両方をチェックします。If the compatibility level is 90 or less, unless NOINDEX is specified, DBCC CHECKDB 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.
  • SQL Server 2016 以降で、既定では高価な式の評価を避けるために保存される計算列、UDT 列、およびフィルター選択されたインデックスに追加のチェックは実行されません。Starting with SQL Server 2016, 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.

データベースの互換性レベルを調べるTo learn the compatibility level of a database

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

DBCC CHECKDB では、チェックの実行に必要なトランザクションの一貫性を得るため、内部データベース スナップショットを使用します。DBCC CHECKDB uses an internal database snapshot for the transactional consistency needed to perform these checks. これにより、コマンド実行時のブロックや同時実行の問題を回避できます。This prevents blocking and concurrency problems when these commands are executed. 詳細については、次を参照してくださいデータベース スナップショット ( のスパース ファイルのサイズを表示。TRANSACT-SQL と #41 です。 DBCC 内部データベース スナップショットの使用」、およびDBCC & #40 です。TRANSACT-SQL と #41 です。.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 CHECKDB はロックを取得して必要な一貫性を実現します。If a snapshot cannot be created, or TABLOCK is specified, DBCC CHECKDB acquires locks to obtain the required consistency. この場合、割り当てのチェックを行うための排他データベース ロックと、テーブルのチェックを行うための共有テーブル ロックが必要です。In this case, an exclusive database lock is required to perform the allocation checks, and shared table locks are required to perform the table checks. DBCC CHECKDB は、内部データベース スナップショットを作成できない場合は、master に対して実行時に失敗します。DBCC CHECKDB fails when run against master if an internal database snapshot cannot be created. Tempdb に対して DBCC CHECKDB を実行すると、すべて割り当てまたはカタログのチェックは実行されず、テーブルのチェックを実行する共有テーブル ロックを取得する必要があります。Running DBCC CHECKDB against tempdb does not perform any allocation or catalog checks and must acquire shared table locks to perform table checks. これは、パフォーマンス上の理由から、データベースのスナップショットが tempdb では利用できないためです。This is because, for performance reasons, database snapshots are not available on tempdb. つまり、必要なトランザクションの一貫性を実現できないためです。This means that the required transactional consistency cannot be obtained. Microsoft SQL Server 2012 または SQL Server の以前のバージョンでは、ReFS でフォーマットされたボリュームにファイルを持つデータベースに対して DBCC CHECKDB コマンドを実行するときにエラー メッセージが発生する可能性があります。In Microsoft SQL Server 2012 or an earlier version of SQL Server, you may encounter error messages when you run the DBCC CHECKDB command for a database that has its files located on an ReFS-formatted volume. 詳細については、サポート技術情報の記事 2974455 を参照してください: ReFS ボリューム上の SQL Server データベースがある場合に DBCC CHECKDB 動作します。For more information, see Knowledge Base article 2974455: DBCC CHECKDB behavior when the SQL Server database is located on an ReFS volume.

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 CHECKDB を使用する場合は、DBCC によって、ファイル システムとデータベースの間のリンクレベルの一貫性がチェックされます。When using DBCC CHECKDB on a database that stores BLOBs in the file system, DBCC checks link-level consistency between the file system and database. たとえば、テーブルが含まれている場合、 varbinary (max) FILESTREAM 属性を DBCC CHECKDB を使用する列はファイル システムのディレクトリおよびファイルとテーブルの行、列、および列の間の一対一のマッピングがあることを確認値。For example, if a table contains a varbinary(max) column that uses the FILESTREAM attribute, DBCC CHECKDB 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 CHECKDB で破損を修復できます。DBCC CHECKDB 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.

ベスト プラクティスBest Practices

実稼働システムで頻繁に使用する場合は PHYSICAL_ONLY オプションを使用することをお勧めします。We recommend that you use the PHYSICAL_ONLY option for frequent use on production systems. PHYSICAL_ONLY を使用すると、大規模データベースでの DBCC CHECKDB の実行時間を大幅に短縮できます。Using PHYSICAL_ONLY can greatly shorten run-time for DBCC CHECKDB on large databases. また、定期的に、オプションを指定せずに DBCC CHECKDB を実行することもお勧めします。We also recommend that you periodically run DBCC CHECKDB with no options. DBCC CHECKDB を実行する頻度は、個々の業務とその運用環境によって変わります。How frequently you should perform these runs depends on individual businesses and their production environments.

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

既定では、DBCC CHECKDB はオブジェクトの並列チェックを実行します。By default, DBCC CHECKDB performs parallel checking of objects. 並列処理の次数は、クエリ プロセッサによって自動的に決定されます。The degree of parallelism is automatically determined by the query processor. 並列処理の次数の最大値は、並列クエリと同様に構成します。The maximum degree of parallelism is configured just like 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).


この機能は、 SQL ServerSQL Serverのすべてのエディションで使用できるわけではありません。This feature is not available in every edition of SQL ServerSQL Server. 詳細については、並列の整合性の RDBMS の管理性にチェックを参照してください。 SQL Server 2016 の各エディションでサポートされる機能します。For more information, see parallel consistency check in the RDBMS Manageability section of Features Supported by the Editions of SQL Server 2016.

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

DBCC CHECKDB コマンドの終了後、メッセージが SQL ServerSQL Server エラー ログに書き込まれます。After the DBCC CHECKDB command finishes, a message is written to the SQL ServerSQL Server error log. DBCC コマンドが正常に実行された場合、メッセージでは正常に処理されたこととコマンドの実行時間が示されます。If the DBCC command successfully executes, the message indicates success 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 that 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 DescriptionDescription
00 エラー番号 8930 が発生しました。Error number 8930 was raised. このエラーは、メタデータの破損により DBCC コマンドが終了したことを示します。This indicates a corruption in metadata that terminated the DBCC command.
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 corruption in metadata that terminated the DBCC command.
44 アサートまたはアクセス違反が検出されました。An assert or access violation was detected.
55 不明なエラーが発生し、DBCC コマンドが終了しました。An unknown error occurred that terminated the DBCC command.

[エラー報告]Error Reporting

ダンプ ファイル (SQLDUMPnnnn.txt) で作成された、 SQL ServerSQL Server DBCC CHECKDB で破損エラーが検出されるたびに、ログ ディレクトリ。A dump file (SQLDUMPnnnn.txt) is created in the SQL ServerSQL Server LOG directory whenever DBCC CHECKDB 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 CHECKDB コマンドの結果と追加の診断出力が含まれます。The dump file contains the results of the DBCC CHECKDB command and additional diagnostic output. アクセスが制限されて、 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 CHECKDB でエラーが報告された場合は、REPAIR を REPAIR オプションのいずれかを指定して実行するのではなく、データベースのバックアップからデータベースを復元することをお勧めします。If any errors are reported by DBCC CHECKDB, we recommend restoring the database from the database backup instead of running REPAIR with one of the REPAIR options. バックアップが存在しない場合は、修復を実行することによって報告されたエラーを修正します。If no backup exists, running repair corrects the errors reported. 使用する修復オプションは、報告されたエラーのリストの末尾に指定されます。The repair option to use is specified at the end of the list of reported errors. ただし、REPAIR_ALLOW_DATA_LOSS オプションを使用してエラーを修正する場合は、一部のページ (データ) が削除されることがあります。However, correcting the errors by using the REPAIR_ALLOW_DATA_LOSS option might require deleting some pages, and therefore some data. 状況によっては、データベースに、列のデータ型に対して有効ではない値や範囲外の値が入力されていることがあります。Under some circumstances, values might be entered into the database that are not valid or out-of-range based on the data type of the column. DBCC CHECKDB は、すべての列のデータ型について有効ではない列の値を検出します。DBCC CHECKDB can detect column values that are not valid for all column data types. したがって、以前のバージョンの SQL ServerSQL Server からアップグレードしたデータベースに対して DATA_PURITY オプションを指定して DBCC CHECKDB を実行すると、以前から存在していた列の値のエラーが検出される場合があります。Therefore, running DBCC CHECKDB with the DATA_PURITY option on databases that have been upgraded from earlier versions of SQL ServerSQL Server might reveal preexisting column-value errors. SQL ServerSQL Server ではこれらのエラーを自動的に修復することはできないため、列の値を手動で更新する必要があります。Because SQL ServerSQL Server cannot automatically repair these errors, the column value must be manually updated. CHECKDB でこのようなエラーが検出されると、CHECKDB は警告 (エラー番号 2570) を返し、影響を受ける行を特定してエラーを手動で修正するための情報を示します。If CHECKDB detects such an error, CHECKDB returns a warning, the error number 2570, and information to identify the affected row and manually correct the error. 修復は、ユーザーが行われた変更をロールバックできるようにするユーザー トランザクションの下で実行できます。The repair can be performed under a user transaction to let the user roll back the changes that were made. 修復をロールバックしたときは、データベースにエラーが残っているので、データベースをバックアップから復元する必要があります。If repairs are rolled back, the database will still contain errors and must be restored from a backup. 修復が完了したら、データベースをバックアップします。After repairs are completed, back up the database.

データベース緊急モードでのエラーの解決Resolving Errors in Database Emergency Mode

ときに、データベースが設定されて緊急モードを使用して、 ALTER DATABASEステートメントでは、DBCC CHECKDB を実行できますいくつかの特別な修復データベースの場合は、REPAIR_ALLOW_DATA_LOSS オプションを指定します。When a database has been set to emergency mode by using the ALTER DATABASE statement, DBCC CHECKDB can perform some special repairs on the database if the REPAIR_ALLOW_DATA_LOSS option is specified. このような修復により、通常は復旧不可能なデータベースを、物理的な一貫性のある状態でオンラインに戻すことができる場合があります。These repairs may allow for ordinarily unrecoverable databases to be brought back online in a physically consistent state. このような修復は、バックアップからデータベースを復元できない場合にのみ、最終的な手段として使用してください。These repairs should be used as a last resort and only when you cannot restore the database from a backup. データベースが緊急モードに設定されている場合は、データベースは READ_ONLY に設定し、ログ記録を無効にすると、アクセスは、sysadmin 固定サーバー ロールのメンバーに制限します。When the database is set to emergency mode, the database is marked READ_ONLY, logging is disabled, and access is limited to members of the sysadmin fixed server role.


ユーザー トランザクション内で DBCC CHECKDB コマンドを緊急モードで実行したり、実行後にトランザクションをロールバックすることはできません。You cannot run the DBCC CHECKDB command in emergency mode inside a user transaction and roll back the transaction after execution.

データベースが緊急モードのときに、REPAIR_ALLOW_DATA_LOSS 句を指定して DBCC CHECKDB を実行した場合は、次の処理が行われます。When the database is in emergency mode and DBCC CHECKDB with the REPAIR_ALLOW_DATA_LOSS clause is run, the following actions are taken:

  • DBCC CHECKDB では、I/O エラーまたはチェックサム エラーが原因でアクセス不可とマークされたページが、エラーが発生しなかった場合と同様に使用されます。DBCC CHECKDB uses pages that have been marked inaccessible because of I/O or checksum errors, as if the errors have not occurred. これにより、データベースからのデータ復旧の可能性が高くなります。Doing this increases the chances for data recovery from the database.
  • DBCC CHECKDB では、標準的なログ ベースの復旧方法により、データベースの復旧が試行されます。DBCC CHECKDB attempts to recover the database using regular log-based recovery techniques.
  • トランザクション ログが壊れているためにデータベース復旧が失敗した場合、トランザクション ログは再構築されます。If, because of transaction log corruption, database recovery is unsuccessful, the transaction log is rebuilt. ただし、トランザクション ログの再構築の結果、トランザクションの一貫性が失われる場合があります。Rebuilding the transaction log may result in the loss of transactional consistency.

REPAIR_ALLOW_DATA_LOSS オプションは、サポートされている SQL ServerSQL Server の機能です。The REPAIR_ALLOW_DATA_LOSS option is a supported feature of SQL ServerSQL Server. ただし、データベースを物理的に一貫性のある状態にすることが、常に最適なオプションというわけではありません。However, it may not always be the best option for bringing a database to a physically consistent state. 成功した場合、REPAIR_ALLOW_DATA_LOSS オプションによりいくつかデータが失われることがあります。If successful, the REPAIR_ALLOW_DATA_LOSS option may result in some data loss. 実際には、ユーザーが最後の既知の良好なバックアップからデータベースを復元する場合よりも、失われるデータが多い場合があります。In fact, it may result in more data lost than if a user were to restore the database from the last known good backup. MicrosoftMicrosoft では、DBCC CHECKDB によって報告されたエラーから回復する主要な方法として、ユーザーが最後の既知の良好なバックアップから復元することが常に推奨されています。 always recommends a user restore from the last known good backup as the primary method to recover from errors reported by DBCC CHECKDB. REPAIR_ALLOW_DATA_LOSS オプションは、既知の適切なバックアップから復元する代替手段ではありません。The REPAIR_ALLOW_DATA_LOSS option is not an alternative for restoring from a known good backup. これは、緊急時の「最後の手段」のオプションで、バックアップからの復元ができない場合にのみ使用することをお勧めします。It is an emergency “last resort” option recommended for use only if restoring from a backup is not possible.

ログの再構築後、完全な ACID の保証はありません。After rebuilding the log, there is no full ACID guarantee.

ログの再構築後、DBCC CHECKDB が自動的に実行され、物理的な一貫性の問題を報告して修正します。After rebuilding the log, DBCC CHECKDB will be automatically performed and will both report and correct physical consistency issues.

論理データの一貫性とビジネス ロジックに適用される制約を手動で検証する必要があります。Logical data consistency and business logic enforced constraints must be validated manually.

トランザクション ログのサイズは、既定のサイズのままなので、最近のサイズに手動で調整する必要があります。The transaction log size will be left to its default size and must be manually adjusted back to its recent size.

DBCC CHECKDB コマンドが正常に終了した場合、データベースでは物理的な一貫性が保たれ、データベースの状態は ONLINE に設定されます。If the DBCC CHECKDB command succeeds, the database is in a physically consistent state and the database status is set to ONLINE. ただし、データベースにはトランザクション上一貫しない部分が 1 つ以上含まれる可能性があります。However, the database may contain one or more transactional inconsistencies. 実行することをお勧めDBCC CHECKCONSTRAINTSを任意のビジネス ロジックの欠陥を特定し、すぐにデータベースをバックアップします。We recommend that you run DBCC CHECKCONSTRAINTS to identify any business logic flaws and immediately back up the database. DBCC CHECKDB コマンドが失敗した場合、データベースを修復することはできません。If the DBCC CHECKDB command fails, the database cannot be repaired.

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

REPAIR_ALLOW_DATA_LOSS オプションを指定して DBCC CHECKDB コマンドを実行すると、レプリケーションで使用されるユーザー データベース (パブリケーション データベースおよびサブスクリプション データベース) とディストリビューション データベースに影響が生じる場合があります。Running the DBCC CHECKDB command with the REPAIR_ALLOW_DATA_LOSS option can affect user databases (publication and subscription databases) and the distribution database used by replication. パブリケーション データベースとサブスクリプション データベースには、パブリッシュされたテーブルとレプリケーション メタデータ テーブルが含まれます。Publication and subscription databases include published tables and replication metadata tables. これらのデータベースでは、次の問題が発生する可能性があります。Be aware of the following potential issues in these databases:

  • パブリッシュされたテーブル。Published tables. 破損したユーザー データを修復するため CHECKDB 処理によって実行されるアクションが、レプリケートされない場合があります。Actions performed by the CHECKDB process to repair corrupt user data might not be replicated:
  • マージ レプリケーションでは、パブリッシュされたテーブルに対する変更を追跡するために、トリガーを使用します。Merge replication uses triggers to track changes to published tables. CHECKDB 処理で行が挿入、更新、または削除された場合、トリガーは起動しません。このため、変更はレプリケートされません。If rows are inserted, updated, or deleted by the CHECKDB process, triggers do not fire; therefore, the change is not replicated.
  • トランザクション レプリケーションではトランザクション ログを使用して、パブリッシュされたテーブルに対する変更を追跡します。Transactional replication uses the transaction log to track changes to published tables. その後、ログ リーダー エージェントは変更をディストリビューション データベースに移動します。The Log Reader Agent then moves these changes to the distribution database. DBCC 修復の一部は、ログには記録されますが、ログ リーダー エージェントでレプリケートできません。Some DBCC repairs, although logged, cannot be replicated by the Log Reader Agent. たとえば、CHECKDB 処理によってデータ ページの割り当てが解除された場合、ログ リーダー エージェントではこの処理が DELETE ステートメントに変換されません。このため、変更はレプリケートされません。For example, if a data page is deallocated by the CHECKDB process, the Log Reader Agent does not translate this to a DELETE statement; therefore, the change is not replicated.
  • レプリケーション メタデータ テーブル。Replication metadata tables. 破損したレプリケーション メタデータ テーブルを修復するため CHECKDB 処理で実行されるアクションでは、レプリケーションの削除と再構成が必要になります。Actions performed by the CHECKDB process to repair corrupt replication metadata tables require removing and reconfiguring replication.

ユーザー データベースまたはディストリビューション データベースで、REPAIR_ALLOW_DATA_LOSS オプションを指定して DBCC CHECKDB コマンドを実行する必要がある場合は、次の手順に従います。If you have to run the DBCC CHECKDB command with the REPAIR_ALLOW_DATA_LOSS option on a user database or distribution database:

  1. システムを停止します。データベースの操作と、レプリケーション トポロジの他のすべてのデータベースの利用を停止した後、すべてのノードの同期を試行します。Quiesce the system: Stop activity on the database and at all other databases in the replication topology, and then try to synchronize all nodes. 詳細については、「レプリケーション トポロジの停止 (レプリケーション Transact-SQL プログラミング)」を参照してください。For more information, see Quiesce a Replication Topology (Replication Transact-SQL Programming).
  2. DBCC CHECKDB を実行します。Execute DBCC CHECKDB.
  3. DBCC CHECKDB レポートで、ディストリビューション データベースの任意のテーブルまたはユーザー データベースのレプリケーション メタデータ テーブルの修復が示されている場合は、レプリケーションを削除して再構成します。If the DBCC CHECKDB report includes repairs for any tables in the distribution database or any replication metadata tables in a user database, remove and reconfigure replication. 詳細については、「パブリッシングの無効化と配布」を参照してください。For more information, see Disable Publishing and Distribution.
  4. DBCC CHECKDB レポートで、レプリケートされたテーブルの修復が示されている場合は、データ検証を実行して、パブリケーション データベースとサブスクリプション データベースのデータ間に違いがあるかどうかを確認します。If the DBCC CHECKDB report includes repairs for any replicated tables, perform data validation to determine whether there are differences between the data in the publication and subscription databases.

結果セットResult Sets

DBCC CHECKDB は以下の結果セットを返します。DBCC CHECKDB returns the following result set. ESTIMATEONLY オプション、PHYSICAL_ONLY オプション、または NO_INFOMSGS オプションを指定した場合以外は、値が異なることがあります。The values might vary except when the ESTIMATEONLY, PHYSICAL_ONLY, or NO_INFOMSGS options are specified:

 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 は以下の結果セット (メッセージ) を返します。DBCC CHECKDB returns the following result set (message) when NO_INFOMSGS is specified:

 The command(s) completed successfully.

PHYSICAL_ONLY を指定した場合、DBCC CHECKDB は以下の結果セットを返します。DBCC CHECKDB returns the following result set when PHYSICAL_ONLY is specified:

 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 は以下の結果セットを返します。DBCC CHECKDB returns the following result set when ESTIMATEONLY is specified.

 Estimated TEMPDB space needed for CHECKALLOC (KB)    



 (1 row(s) affected)   

 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 固定データベース ロールのメンバーシップが必要です。Requires membership in the sysadmin fixed server role or the db_owner fixed database role.


A.A. 現在のデータベースと別のデータベースの両方をチェックするChecking both the current and another database

次の例では実行DBCC CHECKDB現在のデータベースと、 AdventureWorks2012AdventureWorks2012データベース。The following example executes DBCC CHECKDB for the current database and for the AdventureWorks2012AdventureWorks2012 database.

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

B.B. 情報メッセージを表示せずに現在のデータベースをチェックするChecking the current database, suppressing informational messages

次の例では、現在のデータベースをチェックし、すべての情報メッセージを表示しないようにします。The following example checks the current database and suppresses all informational messages.


参照See Also

DBCC (Transact-SQL)DBCC (Transact-SQL)
データベース スナップショットのスパース ファイルのサイズを表示する方法 (Transact-SQL)View the Size of the Sparse File of a Database Snapshot (Transact-SQL)
sp_helpdb & #40 です。TRANSACT-SQL と #41 です。sp_helpdb (Transact-SQL)
システム テーブルと #40 です。TRANSACT-SQL と #41 です。System Tables (Transact-SQL)