SQL Server數據庫偶爾會進入“恢復中”模式，這往往會讓數據庫管理員措手不及。這種狀態發生在重新啟動、數據庫恢復或非預期關機期間，因為SQL Server正在重放或撤消不完整的事務以維護數據完整性。儘管這個過程通常是自動的，但有時可能需要比預期更長的時間 — 或者甚至看起來卡住了 — 這會讓管理員不確定應該如何繼續進行。
如果您遇到這個問題，不用擔心。本文將幫助您了解背後發生了什麼，並教您如何應對。以下是您將學到的內容的快速概述：
- “恢復中”模式的含義 — 您的數據庫進入此狀態的原因以及SQL Server在後台正在進行的工作。
- 恢復的三個階段 — SQL Server在恢復期間遵循的分析、重做和撤消階段的明確分解。
- 延遲的常見原因 — 從大型事務日誌到過多的虛擬日誌文件（VLFs），看看可能拖慢流程的原因。
- 如何恢復上線 — 學習將數據庫恢復到一致狀態的實用步驟，從等待到使用SQL修復工具。
- 何時尋求進階幫助 — 如果恢復過程似乎卡住且沒有任何進展，應該怎麼做。
通過閱讀本指南，您將對SQL Server的恢復過程有深入的了解，並了解可以用來盡快使數據庫恢復上線的工具。
理解SQL Server中的“恢復中”模式
當 SQL Server 重新啟動或從備份還原數據庫時，它會進入「恢復中」模式以維護數據完整性。在此階段，SQL Server 會重放或撤消未完成的事務，以防止數據損壞並確保事務一致性。
重新啟動 SQL Server 後，數據庫會進入「恢復中」模式。在啟動時或從備份還原數據庫時，您也可能會看到 SQL Server 數據庫處於恢復狀態。
圖 1- SQL 數據庫「恢復中」模式
數據庫的「恢復中」狀態意味著數據庫正在執行恢復過程，一旦過程完成，它將自動上線。然而，您可能會遇到恢復過程緩慢，數據庫陷入恢復狀態的情況。根據數據庫文件大小不同，您的數據庫可能仍然處於恢復狀態，因為 SQL 數據庫需要經歷三個恢復階段，這可能需要一段時間。
SQL 數據庫恢復的三個階段
通常，在 SQL Server 重新啟動時，如果數據庫沒有正確關閉，它會進行崩潰恢復，以確保數據庫保持一致。SQL 數據庫需要經歷三個恢復階段：
階段 1：分析
這個階段從“最後的檢查點到交易記錄結束”開始。它創建一個‘Dirty Page Table’（DPT）表來幫助確定崩潰時的所有髒頁。同時，它還創建了一個‘Active Transaction Table’（ATT）表來識別SQL Server停止時未提交的交易。
階段2：重做
在這個階段，SQL Server將所有在檢查點之後且在崩潰之前發生的更改進行重放。基本上，在重做階段，所有已提交但尚未通過檢查點寫入SQL數據文件（.mdf/.ldf）的交易都需要被向前滾動。
階段3：撤銷
如果在數據庫恢復時有任何未提交的交易，它們必須在撤銷階段中被回滾以使數據庫處於一致狀態。
如果您的數據庫陷入恢復模式怎麼辦？
檢查SQL Server錯誤日誌，查看數據庫中可能類似以下的第一條消息：
Starting up database ‘DatabaseName’
這表示數據庫文件已打開，恢復過程已啟動。稍後，您應該看到SQL Server進行3個恢復階段。如果您想獲得有關如何備份和還原數據庫的指南，請查看這份有關備份和還原Azure SQL數據庫的指南。
數據庫恢復的第1階段如下所示：
Recovery of database ‘DatabaseName’ (9) is 0% complete (approximately 95 seconds remain). Phase 1 of 3. This is an informational message only. No user action is required.
Recovery of database ‘DatabaseName’ (9) is 3% complete (approximately 90 seconds remain). Phase 1 of 3. This is an informational message only. No user action is required.
在第1階段完成後，SQL Server將進行第2和第3階段的恢復：
Recovery of database ‘DatabaseName’ (9) is 5% complete (approximately 85 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required…
Recovery of database ‘DatabaseName’ (9) is 95% complete (approximately 40 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.
Phase 3 of 3. This is an informational message only. No user action is required.
一旦第2和第3階段完成，您將看到類似於：
3807 transactions rolled forward in database ‘DatabaseName’ (9). This is an informational message only. No user action is required.
0 transactions rolled back in database ‘DatabaseName’ (9). This is an informational message only. No user action is required.
Recovery is writing a checkpoint in database ‘DatabaseName’ (9). This is an informational message only. No user action is required.
Recovery completed for database DatabaseName (database ID 9) in 30 second(s) (analysis 1289 ms, redo 29343 ms, undo 72 ms.) This is an informational message only. No user action is required.
在錯誤日誌中，請注意消息“無需用戶操作”。這表示數據庫處於恢復狀態。然而，恢復可能需要比預期更長的時間，數據庫將被困在恢復模式中。
SQL數據庫被困在“恢復中”模式背後的原因
以下是可能導致SQL數據庫被困在恢復模式中的原因：
- 一個長時間運行的事務正在回滾
- 事務日誌文件大小巨大
- 事務日誌內有太多虛擬日誌文件（VLF）
- SQL Server中存在錯誤，現在已修復。
您可以採取哪些措施將數據庫恢復到一致狀態？
解決方法1：等待數據庫恢復完成
將數據庫帶回線上的最明顯解決方案是耐心等待恢復過程完成；這可能需要幾個小時或幾天。如果對於SQL Server 2008或2008 R2中的DB來說，恢復所需的時間比預期長，則應用Microsoft修復可能有所幫助。
注意：避免執行 RESTORE 命令以將資料庫帶入一致狀態，因為 SQL Server 已經在嘗試執行相同的任務。而執行 ‘RESTORE with..Recovery’ 意味著讓資料庫再次經歷相同的步驟。
解決方法 2：使用專業的 SQL 數據庫修復工具
如果恢復完成但無法將資料庫帶入一致狀態，使用專門的 SQL 修復工具可能有助於將資料庫恢復到其原始狀態。
- Stellar Repair for MS SQL — 一款專門的工具，可在數據損壞或故障後幫助恢復 SQL 數據庫到其原始狀態。
- ApexSQL Recover — 此工具幫助恢復已刪除、截斷或損壞的 SQL Server 數據庫數據。
- dbForge SQL Complete — 雖然主要是一個 IDE 擴展，但它提供了有用的錯誤處理和故障排除功能。
- Redgate SQL Data Recovery — Redgate 提供一系列 SQL Server 工具，包括數據恢復功能。
- SysTools SQL Recovery Tool — 以恢復損壞或損壞的 SQL 數據庫文件（.MDF 和 .NDF）而聞名，並將其恢復到可用狀態。
- Kernel for SQL Database Recovery — 此工具可以從損壞和意外關機中恢復和修復 SQL Server 數據庫。
- Aryson SQL Database Recovery — 另一款可以修復和恢復 SQL Server 中的 MDF 和 NDF 文件的工具。
結論
在本文中，我們介紹了當SQL數據庫被卡在“正在恢復”模式時意味著什麼，恢復的三個關鍵階段（分析、重做和撤消），以及您可以採取的措施將數據庫恢復為在線狀態。我們還討論了可能的原因，從大型事務日誌到太多虛擬日誌文件（VLF）。
如果您的SQL數據庫仍然卡在恢復模式中，請記住耐心是關鍵。避免運行RESTORE命令，因為這將重新啟動恢復過程。對於嚴重的問題，如果手動干預失敗，可以考慮使用專業的SQL數據庫修復工具來恢復數據。
如果您覺得這個指南有幫助，請與您的團隊分享，或留下一個帶有您的SQL恢復經驗的評論。
Source:
https://dzone.com/articles/resolving-sql-database-stuck-in-recovery-mode