DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS
All_errormsgsを指定してdbcc checkdb repair_allow_data_lossを実行する必要があり、27時間以上実行されています。 DBサイズが15GBを超え、サーバー（Windows 2008）に32GBのメモリが搭載されています。私はこれをSQL 2005で実行しましたが、前述のとおり、27時間以上かかっています。これは正常ですか？そうでない場合、DBに問題を引き起こさずに終了できますか？実行する前にバックアップを取った。
dBに問題を起こさずに終了できますか
Repair _allow_data_lossを実行するだけで、すでに問題が発生しています。他のすべてのオプションを使い果たした後、データ損失を許可することは、本当に非常に最後の手段です。適切なアクションは、正しいバックアップから復元し、失われたトランザクションを再適用することです。
DBCCは27時間かかりますか？はい、完了までに8日以上かかったDBCCコマンドを知っています。 DBCCがブロックされているかどうか（そしてSharkが適切なアプローチを提供しているかどうか）を調査して確認できます。運が良ければ、ブロックされており、ブロックを解除して終了できます。しかし、あなたができることはあまりないが、それを待つことができるが、進歩している場合
終了すると、データベースはすでにあるよりも悪くなりますか？理論上は、DBCCは他の操作と同様に過渡的に一貫しており、進行中の操作はすべてロールバックされるためです。ただし、実際には、DBCC修復を実行しているという事実は、破損した構造を処理していることを意味し、そのような場合には常にリスクが伴います。
実行する前にバックアップを取った。
別のマシンに、または同じインスタンスの別のDBとして復元することにより、バックアップを検証します。バックアップが正しい場合は、いつでもこのバックアップに戻ることができるので、はるかに良い場所にいます。また、バックアップを取った後、新しいビジネストランザクションが発生していないことを確認してください。