SQL Server 資料庫顯示 Recovery Pending 或 Suspect：如何安全復原而不擴大資料損毀？
Recovery Pending 和 Suspect 說明資料庫無法完成復原。應先保護檔案和日誌，檢查 I/O、空間、權限與錯誤號，再決定還原或修復。
先控制風險，再實施變更建議先在測試環境或單一對象上驗證，保存設定、日誌和可復原備份。涉及生產切換、批次策略、資料庫修復或儲存重建時，應設定維護時段和明確復原條件。
1. 結論與適用範圍
資料庫狀態異常是結果，不是根因。儲存掉線、磁盤壞塊、權限變化、日誌檔案丟失、空間不足、異常關機和底層檔案系統錯誤都可能觸發。首先要停止反復附加、脫機和修復操作，保存現場並確定是否存在可用備份。
該問題涉及 SQL Server、ERP、資料庫復原或版本遷移。任何高風險操作前都應保留可驗證備份。
2. 需要優先關注的風險信號
- 資料庫狀態為 RECOVERY_PENDING、SUSPECT 或 EMERGENCY，應用程式全部無法連線。
- ERRORLOG 出現 823、824、825、9001、5120、5173 等 I/O 或檔案錯誤。
3. 遷移或處理前的檢查清單
- 複寫並保護 MDF、NDF、LDF 和 ERRORLOG，記錄當前時間、磁盤和服務狀態。
- 檢查 Windows 系統/應用程式事件、儲存控制器、RAID、檔案系統、空間和目錄權限。
- 確認資料庫檔案路徑、檔案是否完整、日誌是否被刪除或流動。
- 盤點完整、差異和日誌備份，驗證可復原到哪個時間點。
唯讀檢查與驗證範例
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;corp.example、192.0.2.0/24 與 203.0.113.0/24 均為檔案範例。只有在確認實際環境參數後，才能取代為實際值。
4. 推薦實施步驟
- 優先在隔離環境從備份還原並驗證，生產原檔案保持不動。
- 修復儲存和權限根因後再嘗試正常復原。
- 只有無可用備份且業務接受資料丟失時，才評估 EMERGENCY 模式和 REPAIR_ALLOW_DATA_LOSS。
- 修復後導出資料到新資料庫，不把經過強制修復的庫繼續當作長期生產庫。
遙距還是現場處理？日誌、設定和少量對象通常可先遙距評估；涉及物理伺服器、儲存、機房供電、批次切換或復原演練時，應安排受控現場維護時段。浙江、上海、江蘇可根據項目情況上門，其他地區可遙距協助。
5. 驗證、復原與常見誤區
- DBCC CHECKDB 無一致性錯誤，資料庫可多次重新啟動復原。
- 應用程式、作業、備份和關鍵資料核對透過。
- 底層磁盤、RAID、檔案系統和事件日誌不再錯誤訊息。
常見錯誤做法
- 直接刪除 LDF 後重新附加。
- 在唯一原始檔案上運行允許資料丟失的修復。
- 只把資料庫改成 ONLINE，不檢查儲存根因。
常見問題
Recovery Pending 和 Suspect 有甚麼區別？
前者通常表示復原尚未開始或資源不可用，後者表示復原失敗；都需要查看具體錯誤。
REPAIR_ALLOW_DATA_LOSS 能否直接使用？
不能作為首選。它可能刪除損壞頁或對象，只適用於沒有可用備份且接受損失的最後手段。