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

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

最初に切り分ける範囲

このサーバー／データベースの事象では、まず「SQL ERRORLOG」と「データ／ログファイルへのアクセス可否」で障害境界を決め、その後「ディスク容量と I/O」へ進みます。本番設定を変更する前に、現状、発生時刻、正常な比較対象を記録します。

依存関係に沿った確認順序

SELECT name, state_desc FROM sys.databases;

根拠を確認してから変更する

1. まず読み取り中心で証跡を取得し、設定変更前に「SQL ERRORLOG のエラーコード」と「データ／ログファイルへのアクセス可否」を確認します。
2. 最初の確認が正常なら「ディスク容量と I/O」と「サービスアカウントの権限」へ進み、障害時刻と結び付く証跡を残します。
3. 証跡が症状を説明できる場合に限って設定を変更します。「バックアップの復元可能性」を変更する前に元の値と切り戻し条件を定義します。
4. 「破壊的修復を避けるための保護策」は限定範囲で検証してから、本番ユーザーまたは本番トラフィックへ展開します。

復旧確認と切り戻し

• ユーザーまたはアプリケーションの一連の業務動作を確認し、「SQL ERRORLOG のエラーコード」単独の状態だけで完了としません。
• 変更後に「バックアップの復元可能性」と「破壊的修復を避けるための保護策」を再確認し、新たな迂回、権限拡大、二次障害がないことを確認します。
• 「SQL ERRORLOG のエラーコード」から「破壊的修復を避けるための保護策」までの証跡、変更前後の設定、業務確認結果、切り戻し点を保存します。

よくある誤判断

• 「SQL ERRORLOG」と「データ／ログファイルへのアクセス可否」を同時に変更し、どちらが原因だったか追跡できなくすること。
• 「ディスク容量と I/O」が正常というだけで、「サービスアカウントの権限」を含む業務経路全体も正常と判断すること。
• 「バックアップの復元可能性」または「証跡を確保する前に破壊的な修復を実行しない」の一時例外を、責任者・期限・切り戻し記録なしで本番に残すこと。

関連する確認事項