SQL Server DB が「復旧保留」または「疑わしい」状態になった場合の安全な対応

Recovery Pending／Suspect は復旧処理を完了できない状態です。ファイルとログを保護し、I/O、容量、権限、エラー番号を調査します。

1. 結論と対象範囲

異常状態は原因ではなく結果です。ストレージ切断、媒体障害、権限変更、ログ消失、容量不足、異常終了、ファイルシステム障害で発生します。アタッチ、デタッチ、修復を繰り返さず、現物を保護して有効バックアップを確認します。

SQL Server、ERP、DB 復旧、版移行に関係します。高リスク操作前に検証済みバックアップを保護します。

2. 優先して確認するリスク兆候

• DB が RECOVERY_PENDING、SUSPECT、EMERGENCY となり、全アプリ接続が失敗する。
• ERRORLOG に 823、824、825、9001、5120、5173 などの I/O／ファイルエラーがある。

3. 変更前の確認項目

1. MDF、NDF、LDF、ERRORLOG を複製保護し、時刻、ディスク、サービス状態を記録します。
2. Windows System／Application、コントローラー、RAID、ファイルシステム、空き容量、権限を確認します。
3. 全 DB ファイル経路と、ログ削除・移動・切詰めの有無を確認します。
4. 完全、差分、ログバックアップを棚卸しし、復元可能時点を確定します。

SELECT name,state_desc,user_access_desc FROM sys.databases;
EXEC xp_readerrorlog 0,1,N"Error";
DBCC CHECKDB (N"DatabaseName") WITH NO_INFOMSGS, ALL_ERRORMSGS;

4. 推奨実施手順

1. 本番ファイルを触らず、隔離環境へバックアップ復元して検証する方法を優先します。
2. ストレージと権限の原因を直してから通常回復を試します。
3. 有効バックアップがなく、業務が損失を承認した場合だけ EMERGENCY と REPAIR_ALLOW_DATA_LOSS を検討します。
4. 強制修復後は検証済みデータを新 DB へ移し、修復済み DB を長期本番にしません。

5. 検証、切戻し、よくある誤り

• DBCC CHECKDB に整合性エラーがなく、複数回再起動して回復します。
• アプリ、ジョブ、バックアップ、重要データ照合が通ります。
• ディスク、RAID、ファイルシステム、イベントに基礎障害がありません。

よくある誤り

• LDF を削除して再アタッチする。
• 唯一の原本でデータ損失修復を実行する。
• ONLINE に戻すだけでストレージ原因を調べない。

よくある質問

Recovery Pending と Suspect の違いは何ですか。

前者は資源不足などで回復開始不能、後者は回復失敗を示すことが多く、具体的エラーで判断します。

REPAIR_ALLOW_DATA_LOSS をすぐ使えますか。

使いません。ページやオブジェクトを削除し得るため、有効バックアップがなく損失承認済みの最終手段です。