DBCC CHECKDB: MS 完全ガイド SQL Server データベースの健全性（2026年）

DBCC CHECKDBは SQL Serverの主要なデータベース整合性ツールです。例を使って使い方を学び、破損を修正し、パフォーマンスを最適化する方法を学びましょう。

3. DBCC CHECKDB の実行: ステップバイステップ

3.1の前提条件

以下は、DBCC CHECKDB 操作を実行する前のチェックリストです。

• 完全なデータベースバックアップ – 破損が発見されたり修復操作が必要になったりした場合の安全策として、整合性チェックを実行する前に完全バックアップを作成してください。
• 適切な権限 – DBCC CHECKDBコマンドを実行するには、sysadminまたはdb_owner権限が必要です
• 十分なシステムリソース:
  • メモリ: データベースサイズの25%
  • Tempdb スペース: データベース サイズの 10 ～ 15%
  • CPU: メンテナンス中の可用性は50～70%
  • I/O: 大量の読み取り操作が予想される
• データベースのアクセシビリティ – CHECKDBはすべてのデータベースページへの読み取りアクセスを必要とするため、データベースがアクセス可能であり、制限された状態ではないことを確認してください。

3.2 基本コマンド

Most 基本的な DBCC CHECKDB コマンドには、次の 3 つの一般的なバリエーションがあります。

（1）現在のデータベースを確認する（パラメータなし）

DBCC CHECKDB

（2）データベースを名前で確認する：

DBCC CHECKDB ('YourDatabaseName')

(3) ID でデータベースを確認します:

DBCC CHECKDB(5)  -- Replace 5 with your database ID

この基本的なコマンドは、指定されたデータベースの完全な整合性チェックを実行し、すべてのテーブル、インデックス、およびシステム構造を検査します。スペースを含まない標準名のデータベースの場合は、引用符を省略できます。コマンドは完了するまで実行され、進行状況メッセージと最終結果が表示されます。この基本構文は、小規模なデータベースや、メンテナンスに十分な時間がある場合に最適です。

以下はDBCC CHECKDBを実行しているスクリーンショットです。 SQL Server 管理スタジオ (SSMS):

3.3 完全なオプション

以下は DBCC CHECKDB の完全なオプションです。

カテゴリー	オプション	詳細説明	DBCC CHECKDBの例
修理オプション	REPAIR_REBUILD	データ損失のない修復（例：インデックスの再構築）	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	修理不可。下位互換性のみ	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	すべてのエラーを修復します（データ損失が発生する可能性があります）	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
スコープ制御	NOINDEX	非クラスター化インデックスのチェックをスキップします	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	物理的なストレージの整合性（ページ/レコード）のみをチェックします	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	論理列値のエラー（無効な日付など）をチェックします	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	詳細な論理チェック（インデックス付きビュー、XML/空間インデックス）	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
出力制御	ALL_ERRORMSGS	すべてのエラーを表示します（デフォルト: オブジェクトあたり 200 件）	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	情報メッセージを非表示にする	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
パフォーマンス	TABLOCK	テーブルロックを使用します（TempDB の使用量は減りますが、書き込みはブロックされます）	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	並列処理設定を上書きする	DBCC CHECKDB ('MyDB', MAXDOP = 2)
ユーティリティ	ESTIMATEONLY	必要な TempDB スペースを推定します。(実際のチェックは行われません)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. 結果を理解する

DBCC CHECKDB は、実行が正常に完了したかどうかによって異なる結果を生成します。それぞれについて詳しく説明します。

4.1 CHECKDBの実行が正常に完了しました

DBCC CHECKDB の実行が正常に完了すると、データベースの正常性状態に応じてさまざまな種類の結果が報告されます。

4.1.1 問題は見つかりませんでした

DBCC CHECKDB で問題が見つからない場合は、次のような出力が表示されます。

CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

この結果は、データベースがチェックされたすべての構造にわたって完全な整合性を維持していることを示しています。

4.1.2 破損エラーが見つかりました

DBCC CHECKDB が破損エラーを検出すると、次の構造のエラー メッセージが報告されます。
重大度レベルガイド:

• レベル16-19： ユーザーが修正可能なエラー（多くの場合は軽微な破損）
• レベル20-24： システムエラー、重大な破損のため、直ちに対処が必要です
• レベル25： 致命的なエラー、データベースにアクセスできない可能性があります

一般的なエラーには次のようなものがあります。

• ページチェックサムエラー（メッセージ824）
• 割り当てエラー（メッセージ 8928）
• インデックスの一貫性の問題（メッセージ 8964）

メッセージ構造を理解すると、対応アクションの優先順位を決定し、適切な回復戦略を決定するのに役立ちます。

4.1.3 一般的な情報メッセージと警告メッセージ

DBCC CHECKDBの出力は必ずしも深刻な問題を示すわけではありません。以下のような情報メッセージや警告メッセージも出力されることがあります。

• 修復ステートメント – 軽微な問題を修正するための修復コマンドを提案するメッセージ
• 割り当て警告 – データアクセスに影響を与えないスペース割り当てに関する警告
• パフォーマンスに関する推奨事項 – インデックスのメンテナンスと最適化に関する提案
• 情報通知 – すぐに対応を必要としない一般的なステータスメッセージ

これらのメッセージは、即時の対応を必要とする重大な破損と、通常のメンテナンス期間中に対処できる軽微な問題を区別しながら、貴重なメンテナンス ガイダンスを提供します。

警告メッセージの例:

DBCC results for 'InventoryDatabase'.
Msg 2570, Level 16, State 3, Line 1
Page (2:8452), slot 17 in object ID 485577333, index ID 0, partition ID 72057594038845456, 
alloc unit ID 72057594042515968 (type "In-row data").
Column "ProductPrice" value is out of range for data type "decimal". Update column to a legal value.
There are 45892 rows in 1247 pages for object "Products".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Products' (object ID 485577333).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'InventoryDatabase'.

4.2 CHECKDB実行の中止

CHECKDB がさまざまな理由により実行中に中止された場合、エラー メッセージが報告され、以下の状態コードを含むエラー ログが追加されます。

州／地域	詳細説明
0	エラー番号8930が発生しました。これはメタデータの破損によりDBCCコマンドが終了していることを示しています。
1	エラー番号 8967 が発生しました。内部 DBCC エラーが発生しました。
2	緊急モードのデータベース修復中にエラーが発生しました。
3	これは、メタデータが破損し、DBCC コマンドが終了していることを示します。
4	アサートまたはアクセス違反が検出されました。
5	不明なエラーが発生したため、DBCC コマンドが終了しました。

エラーメッセージの例:

Failed:(-1073548784) Executing the query "DBCC CHECKDB('InventoryDB') WITH NO_INFOMSGS" failed with the following error: "There is insufficient system memory to run this query.Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

または

2024-11-18 09:52:41.38 spid35 I/O error (bad page ID) detected during read at offset 0x00000024886000 in file 'C:\Data\MSSQL\DATA\SalesDatabase.mdf'.

エラーログの例:

11/15/2024 09:23:17,spid52,Unknown,DBCC CHECKDB (SalesDatabase) WITH all_errormsgs no_infomsgs executed by CORP\dbadmin terminated abnormally due to error state 3. Elapsed time: 1 hours 32 minutes 18 seconds.

このような場合には、次のような代替の詳細オプションを試すことができます。 DataNumen SQL Recovery データベースの破損を修正します。

5. 破損エラーの修正

5.1 バックアップと復元：最も安全な解決策

DBCC CHECKDBが破損エラーを識別した場合、クリーンなバックアップから復元するのが最も安全で、ost 信頼性の高いソリューションです。このアプローチは、データの整合性を保証しながら、根本的な破損の原因を排除します。復元前に、以下の方法でバックアップの整合性を検証してください。 復元確認のみ コマンドを実行し、データ損失を最小限に抑えるためのポイントインタイムリカバリオプションを検討してください。ハードウェアの問題やソフトウェアのバグが発生した場合、再発防止のために追加の注意が必要になる可能性があるため、破損の詳細を文書化して根本原因分析に役立ててください。

5.2 ページレベルの破損の解決策

小さなデータ部分に影響を与える孤立したページ破損の場合、 SQL Server Enterprise Editionは、データベース全体を復元することなく、特定の破損ページを修復するページ復元機能を提供します。この高度な手法には、完全な復旧モデルと最新のログバックアップが必要です。

ページの復元手順:

1. 破損したページを特定する CHECKDBエラーメッセージから（例：ページ1:256）
2. 現在のログバックアップを取得する 最近の取引をキャプチャするには:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'

3. 破損したページを復元する mからost 最近の完全バックアップ:

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'

4. 差分バックアップを適用する （可能な場合は）：

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'

5. すべてのログバックアップを適用する 今作成したものも含め、順番に:

RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'

6. 最終的なログバックアップと復元 ページを最新の状態にするには:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

重要でないデータの代替手段: 破損が重要でないデータに影響する場合は、破損した構造を再構築する前に、影響を受けていない行を新しいテーブルにエクスポートすることができます。

-- Export good data to a new table
SELECT * INTO YourTable_Backup 
FROM YourTable 
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)

-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data

5.3 インデックス破損のクイックフィックス

インデックスの破損は、多くの場合、基礎となるテーブル データに影響を与えずにインデックス構造を再作成する再構築操作によって改善されます。

ALTER INDEX ALL ON YourTable REBUILD

このアプローチは、再構築によってソース テーブル データからインデックス ページが再生成されるため、非クラスター化インデックスの破損に特に有効であり、破損を効果的に排除しながら元の情報をすべて保持します。

6. REPAIR_REBUILDとREPAIR_ALLOW_DATA_LOSSを使用する

前の方法がすべて失敗するか実行できない場合は、REPAIR_REBUILD および REPAIR_ALLOW_DATA_LOSS オプションを使用してデータベースを修復できます。

6.1 REPAIR_REBUILD (より安全なオプション):

• のために使用します： インデックスの破損と軽微な割り当てエラー
• データの安全性： データを削除せずに破損の修復を試みる
• リスクレベル： 低 – データ損失は予想されません
• 典型的なシナリオ: 非クラスター化インデックスの破損、軽微なメタデータの問題
• コマンド例: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS（最後の手段）:

• のために使用します： バックアップが利用できない場合の重大な破損
• データの安全性： データベースの機能を回復するために破損したデータを削除する場合があります
• リスクレベル： 高 – 永久的なデータ損失の可能性あり
• 典型的なシナリオ: ページ破損、システムテーブルの損傷、割り当てチェーンエラー
• コマンド例: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 これらのオプションのベストプラクティス:

• 常にテスト 可能な場合はデータベースコピーの修復操作
• 常にバックアップ これらのオプションを実行する前に
• すべての変更を文書化する コンプライアンスとトラブルシューティングの目的のため
• データベースをシングルユーザーモードに設定する 修復操作を実行する前に

通常は、 修復_再構築 最初にオプションを選択します。失敗した場合は、 REPAIR_ALLOW_DATA_LOSS オプションを選択します。

6.4 REPAIR_ALLOW_DATA_LOSS の結果

6.4.1 修復は成功するがデータは失われる

時には REPAIR_ALLOW_DATA_LOSS オプションは成功しますが、一部のデータはlですost 修理後。

以下にサンプルメッセージをいくつか示します。

CHECKDB found 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
CHECKDB fixed 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Msg 8909, Level 16, State 1, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 45035996309880832 (type Unknown), page ID (1:553) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
The error has been repaired.
Msg 8939, Level 16, State 98, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 111464090777419776 (type Unknown), page (0:0). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -1.
Could not repair this error.

これは、DBCC CHECKDBが破損したレコードの一部を破棄してデータベースを修復するためですが、実際には、ost それらのうち、まだ回復できるものは DataNumen SQL Recovery.

サンプルファイル:

SQL Server バージョン	破損したMDFファイル	によって修正されたMDFファイル DataNumen SQL Recovery
SQL Server 2014	エラー10_1.mdf （メッセージ8909の後にメッセージ8939が続く）（600件のレコードlost REPAIR_ALLOW_DATA_LOSS 付き)	エラー10_1_修正.mdf （記録なしost)
SQL Server 2014	エラー10_2.mdf （メッセージ8909の後にメッセージ8939が続く）（6000件のレコード（50％）lost REPAIR_ALLOW_DATA_LOSS 付き)	エラー10_2_修正.mdf （100件のレコードのみost)
SQL Server 2014	Error7.mdfファイル （100件のレコードlost REPAIR_ALLOW_DATA_LOSS 付き)	エラー7_修正済み.mdf （レコードは1つだけost)

6.4.2 修理失敗 – 専門家による解決策を検討

If REPAIR_ALLOW_DATA_LOSS 失敗した場合、1 つまたは複数のエラー メッセージが出力されます。

以下はその例です。

DBCC results for ‘MyDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘MyDatabase’.
Msg 824, Level 24, State 2, Line 8
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xea8a9a2f; actual: 0x37adbff8). It occurred during a read of page (1:28) in database ID 39 at offset 0x00000000038000 in file ‘MyDatabase.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Msg 7909, Level 20, State 1, Line 8
The emergency-mode repair failed.You must restore from backup.

Msg 8992, Level 16, State 1, Line 8
Check Catalog Msg 3852, State 1: Row (object_id=69) in sys.objects (type=S ) does not have a matching row (object_id=69,column_id=1) in sys.columns.

Msg 8945, Level 16, State 1, Line 8
Table error: Object ID 41, index ID 1 will be rebuilt.
Could not repair this error.

Msg 2510, Level 16, State 17, Line 8
DBCC checkdb error: This system table index cannot be recreated.
Repair: The Nonclustered index successfully rebuilt for the object “sysidxstats” in database “MyDatabase”.

Msg 8921, Level 16, State 1, Line 8
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 8998, Level 16, State 2, Line 8
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 39 pages from (1:0) to (1:8087). See other errors for cause.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 2575, Level 16, State 1, Line 8
The Index Allocation Map (IAM) page (1:157) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.
Could not repair this error.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘sys.sysrscols’ (object ID 3).

Msg 8948, Level 16, State 3, Line 8
Database error: Page (1:295) is marked with the wrong type in PFS page (1:1). PFS status 0x70 expected 0x60.
The error has been repaired.
Msg 8905, Level 16, State 1, Line 8
Extent (1:296) in database ID 39 is marked allocated in the GAM, but no SGAM or IAM has allocated it.
The error has been repaired.

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.

Msg 5125, Level 24, State 2, Line 2
File ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.mdf’ appears to have been truncated by the operating system. Expected size is 5120 KB but actual size is 5112 KB.
Msg 3414, Level 21, State 1, Line 2
An error occurred during recovery, preventing the database ‘SalesDatabase’ (39:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

Msg 3313, Level 21, State 1, Line 2
During redoing of a logged operation in database ‘SalesDatabase’, an error occurred at log record ID (135:752:2). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.

このようなシナリオでは、次のような専門的なソリューションを使用する必要があります。 DataNumen SQL Recovery データベースを修正します。

サンプルファイル

SQL Server バージョン	破損したMDFファイル	によって修正されたMDFファイル DataNumen SQL Recovery
SQL Server 2014	エラー1_3.mdf （単一メッセージ824）	エラー1_3_修正.mdf
SQL Server 2014	エラー1_1.mdf (継続的なメッセージ824エラー)	エラー1_1_fixed.mdf
SQL Server 2014	エラー1_2.mdf （（メッセージ824の後にメッセージ7909が続く）	エラー1_2_修正.mdf
SQL Server 2014	エラー4_1.mdf （メッセージ8992の後にメッセージ3852が続く）	エラー4_1_修正.mdf
SQL Server 2014	エラー4_2.mdf （メッセージ8992の後にメッセージ3852が続く）	エラー4_2_修正.mdf
SQL Server 2014	エラー5.mdf （メッセージ8945）	エラー5_修正済み.mdf
SQL Server 2014	エラー6.mdf （メッセージ2510）	エラー6_修正済み.mdf
SQL Server 2014	エラー2.mdf （メッセージ2575）	エラー2_修正済み.mdf
SQL Server 2014	エラー11.mdf （メッセージ8905）	エラー11_修正済み.mdf
SQL Server 2014	エラー3.mdf （メッセージ5028）	エラー3_修正済み.mdf
SQL Server 2014	Error8.mdfファイル （メッセージ5125）	Error8_fixed.mdf
SQL Server 2014	エラー9.mdf （メッセージ3313）	エラー9_修正済み.mdf

7. ベストプラクティス

7.1 定期的なCHECKDB操作のスケジュール設定

重要な本番データベースに対しては週次DBCC CHECKDBを実行し、高トランザクションシステムに対しては毎日チェックを実施します。パフォーマンスへの影響を最小限に抑えるため、使用率の低い時間帯に操作をスケジュールし、データベースのサイズとメンテナンス期間に基づいて、フルチェックとPHYSICAL_ONLYオプションを交互に実行することを検討してください。 SQL Server エージェントは、集中的な監視およびアラート機能を提供しながら、一貫した実行を保証します。

7.2 パフォーマンス影響管理

DBCC CHECKDB 操作はシステムリソースを大量に消費するため、同時実行中のユーザーアクティビティに影響を与える可能性があります。チェック中の CPU 使用率、メモリ消費量、ディスク I/O を監視し、パフォーマンスへの影響パターンを把握してください。定期的なチェックには NOINDEX オプションを使用し、完全な検証は月次のメンテナンス期間に確保することを検討してください。整合性チェック期間中の期待値を管理するため、クエリタイムアウトの延長とユーザーとのコミュニケーション戦略を実装してください。

7.3 メンテナンスウィンドウの計画

DBCC CHECKDBのスケジュールは、バックアップ操作、インデックスの再構築、統計情報の更新といった他のメンテナンス作業と調整してください。パフォーマンスの低下やタイムアウトの問題を引き起こす可能性のある、リソースを大量に消費する操作の重複を避けてください。データベースサイズの増加予測に基づいてメンテナンス期間を計画し、データ量の増加に合わせて完全な整合性検証を行うための十分な時間を確保してください。

7.4 自動監視とアラート

構成 SQL Server DBCC CHECKDBが破損を検知すると、エージェントアラートが管理者に即座に通知されます。整合性チェック結果を抽出・分類するログ解析ソリューションを実装することで、傾向分析とプロアクティブな問題特定が可能になります。破損の重大度レベルに応じて対応期間と担当者を定義したエスカレーション手順を作成します。

8. DBCC CHECKTABLE: 軽量な代替手段

8.1 CHECKDBの代わりにCHECKTABLEを使用する場合

DBCC CHECKTABLEは、個々のテーブルに重点を置いた整合性チェックを提供するため、 tar特定のデータベースオブジェクトのトラブルシューティングとメンテナンスを容易にします。CHECKTABLEは、特定のテーブルのパフォーマンス問題を調査する場合、完全なデータベースチェックの間に重要なビジネステーブルを検証する場合、または時間的な制約により完全なデータベース検証が不可能な場合に使用します。このアプローチは、完全なCHECKDB操作が利用可能なメンテナンスウィンドウを超える大規模なデータベースで特に有効です。

8.2 DBCC CHECKTABLEの構文と例

基本的なCHECKTABLEコマンド tar特定のテーブルを取得します:

DBCC CHECKTABLE('YourTable')

CHECKDBと同様に、CHECKTABLEはパフォーマンス最適化のためのNOINDEXや破損修復のための修復パラメータなど、様々なオプションをサポートしています。また、テーブルを正確に識別するためにスキーマ名を指定することもできます。

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

この targeted アプローチにより、営業時間中にシステム パフォーマンスを維持しながら、きめ細かな整合性検証が可能になります。

8.3 大規模データベースのパフォーマンス上の利点

CHECKTABLE操作は、完全なデータベースチェックよりもはるかに高速に完了するため、重要なテーブルの整合性検証をより頻繁に実行できます。このアプローチにより、重要なビジネステーブルを毎日検証しながら、包括的なCHECKDB操作を週次または月次スケジュールに確保できます。リソース消費量が少ないため、CHECKTABLEはユーザーへの影響を最小限に抑えながら本番環境で実行できます。

9. CHECKDBが失敗した場合

DBCC CHECKDB は、次のようなさまざまなシナリオで失敗します。

• DBCC CHECKDBの実行 異常終了する
• DBCC CHECKDBの実行は正常に完了しましたが、 修理オプション データベースの修復に失敗しました。

このようなシナリオでは、データベースの破損を修正するために、より専門的なツールが必要になります。

9.1の紹介 DataNumen SQL Recovery

DataNumen SQL Recovery より高度な機能を提供します:

• 最高の回復率 業界では
• ひどく破損したデータベース ファイルを回復します。
• テーブル、インデックス、ビュー、トリガー、ルール、デフォルトなど、すべてのデータベース オブジェクトを回復します。
• ストアド プロシージャ、スカラー関数、インライン テーブル値関数、および複数ステートメント テーブル値関数をリカバリします。
• 完全に削除されたレコードを回復します。
• 暗号化されたオブジェクトを復号化する SQL Server データベース。
• MDF ファイルをバッチで修復します。
• 包括的な修理オプション。
• 高度なログ記録とレポート。
• すべてのサポート SQL Server バージョン。
• テクニカルサポートの可用性
• 定期的な更新と改善

9.2 成功率の比較

回復成功率は大きく異なります。

• DBCC CHECKDB および CHECKTABLE: 1.27% 平均回収率
• DataNumen: 92.6% 回収率

以下は完全な競合比較です:

9.3 深刻な汚職からの回復

重篤なケースに対応する高度な機能:

• 物理的に損傷したストレージからの復旧
• フォーマットされたドライブやクラッシュしたシステムからの復旧
• ディスクイメージ、バックアップファイル、仮想マシンディスクファイル、テンポから回復するraryファイルなど

9.4 専門的な解決策を検討すべき場合

• 最近のバックアップが利用できません
• DBCC CHECKDBが失敗する
• 深刻な汚職シナリオ
• 重要なビジネスデータの取り扱い
• 時間が重要な場合
• 最大限の回復が不可欠な場合

10.よくある質問

11. 結論

11.1 重要なポイントのまとめ

11.1.1 必須のDBCC CHECKDBコマンドの要約

包括的なデータベースチェックのための基本的なDBCC CHECKDB構文を習得し、パフォーマンスの最適化のためにNOINDEXとPHYSICAL_ONLYオプションを活用し、CHECKTABLEを理解します。 targetedテーブル検証。これらの基本コマンドは、プロアクティブなデータベースメンテナンスの基盤となり、破損の早期検出と体系的な整合性監視を可能にします。

11.1.2 重要なベストプラクティスのリマインダー

整合性チェックを実行する前に必ず最新のバックアップを維持し、データベースの重要度に基づいて定期的なCHECKDB操作をスケジュールし、破損アラートを即座に通知する自動監視を導入してください。定期的な監視による予防は事後対応型アプローチよりも効果的であり、標準的なツールでは不十分な場合、専門的なリカバリソリューションが貴重なバックアップオプションとなることを忘れないでください。

11.2 DBCC CHECKDB を使用する場合と高度なソリューション

定期的な整合性監視と軽微な破損の解決にはDBCC CHECKDBを使用し、組み込みの修復機能では対応できない深刻な破損シナリオには、専門的な復旧ツールを用意しておきましょう。意思決定フレームワークでは、バックアップの可用性、データの重要度、時間的制約、そして破損の重大度を考慮する必要があります。優れたデータベース管理者は、定期的なCHECKDB監視に加え、包括的なバックアップ戦略と、標準的なアプローチが不十分な場合に備えた高度な復旧オプションの認識を組み合わせます。

11.3 DBA のための簡単な毎日のヘルスチェックリスト

DBCC CHECKDB を実行するだけでなく、次の重要な日常的な実践によってデータベースの最適な健全性を維持します。

1. バックアップの整合性を確認する

• スケジュールされたバックアップが正常に完了したことを確認する
• バックアップの読み取り可能性を確認するには、RESTORE VERIFYONLY を使用します。
• オフサイトコピーが同期されアクセス可能であることを確認する

また、からより多くの情報を得ることができます 包括的なガイド SQL Server バックアップ.

2. 一貫性ステータスを確認する

• 夜間実行による自動 DBCC CHECKDB の結果を確認する
• モニター SQL Server 破損警告のエラーログ
• 整合性の欠陥があれば直ちに調査する

3. サーバーの状態を監視する

• CPU、メモリ、ディスクI/Oメトリックを確認する
• tempdb スペースの可用性を確認する
• ブロックされたプロセスと長時間実行されているクエリを特定する

4. デッドロックアクティビティを追跡する

• システムヘルスイベントからデッドロックグラフを確認する
• 問題のあるクエリを特定し、開発チームと連携して最適化する
• デッドロックの被害者数とビジネスへの影響を監視する

重要なリマインダー

• 頻繁なデータベースの縮小を避ける – 断片化が進み、パフォーマンスが低下します。大規模なデータ削除を行った後、本当に必要な場合にのみ縮小してください。
• 監視タスクを自動化する SQL Server 重大な問題に対するアラートを含むエージェント ジョブまたはメンテナンス プラン。
• 災害復旧手順をテストする バックアップが復元可能であり、リカバリ目標が達成可能であることを確認するために、毎週実行します。

この毎日のチェックリストを通常の DBCC CHECKDB 操作と組み合わせることで、プロアクティブな監視と迅速な問題対応を通じてデータベース環境の包括的な保護を実現します。

12。 リファレンス

1. Microsoft Learn。「DBCC CHECKDB (Transact-SQL)」 SQL Server ドキュメントマイクロソフト株式会社。
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn。「DBCC CHECKDB によって報告されるデータベース整合性エラーのトラブルシューティング」 SQL Server ドキュメントマイクロソフト株式会社。
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors