データベースが「未確認／SUSPECT」状態となり、アクセスできなくなった（起動トラブル）：SQL Serverトラブルシューティング（15）（2/2 ページ）

　CHECKDBコマンドを実行すると、以下のような一貫性確認の結果が表示されます。

CHECKDB により、データベース 'DBNAME' に 0 個のアロケーション エラーと 4 個の一貫性エラーが見つかりました。
repair_allow_data_loss は DBCC CHECKDB (DBNAME) で見つかったエラーの最小修復レベルです。

　データベースに一貫性の問題が発生していた場合は、一貫性を修復するための「最小修復レベル」が合わせて表示されます。

　最小修復レベルがrepair_rebuildならばデータが失われることなく修復できます。しかし、上記の例のようにrepair_allow_data_lossだった場合は、修復処理を行うと一部のデータが失われてしまう可能性があります。

　残念ながら、失われてしまうデータが何かを確認する方法はなく、設定されている制約が崩れてしまう可能性もあります（このような事態にならないよう「普段からバックアップを正しく取る体制を整える」ことを強くお勧めします）。

　データベースの修復は、ALTER DATABASEコマンドでデータベースを「シングルユーザー」モードに変更してから、修復オプションを使用したCHECKDBコマンドを実行します。

ALTER DATABASE DBNAME SET SINGLE_USER
GO
DBCC CHECKDB (‘DBNAME’, REPAIR_ALLOW_DATA_LOSS)
GO

　その後、修復状況を確認するために、再度一貫性を確認するCHECKDBコマンドと、制約を確認するCHECKCONSTRAINTSコマンドを実行します。

DBCC CHECKDB (‘DBNAME’)
GO
DBCC CHECKCONSTRAINTS (‘DBNAME’)
GO

　これでエラーが見つからなければ、データベースとしての一貫性が戻ったことになります。データベースの動作モードを「マルチユーザーモード」に変更して、「オンライン」にします。

ALTER DATABASE DBNAME SET MULTI_USER
GO
ALTER DATABASE DBNAME SET ONLINE
GO

　これでデータベースとしての一貫性は修復されました。ただし、アプリケーションとしての一貫性は保証されていません。こちらも別途、忘れずに手動で確認してください。

　なお、障害発生時の切り分けとして「デタッチ」「アタッチ」を使用してオンラインになるかを試す手段もあります。しかし、今回のようにデータベースが破損している状況では、絶対に実行しないでください。デタッチは成功しますが、アタッチに失敗する可能性が大だからです。デタッチ状態ではCHECKDBコマンドを実行できないので、修復させる手段が完全になくなってしまいます（*4）。