SQL Server 資料庫處於復原模式？立即取得 10 個行之有效的修復方案！從簡單修復到進階修復，一步步為您解答。
1.理解 SQL Server 資料庫復原模式
1.1 什麼是恢復模式 SQL Server
當 SQL Server 資料庫顯示“恢復中”狀態，這意味著 SQL Server 正在執行崩潰復原或交易復原以確保資料庫一致性。此自動程序透過重播已提交的交易並回滾未提交的交易來維護資料完整性。
復原模式通常在意外關機、電源故障或資料庫還原期間發生。雖然這是正常的保護機制，但當 SQL Server 資料庫復原時間異常長或出現卡住的情況。
1.2 資料庫復原的三個階段
SQL Server 恢復分為三個不同的階段：
1.2.1 分析階段
SQL Server 從上一個檢查點開始掃描交易日誌，以識別髒頁和活動事務。它會建立髒頁表 (DPT) 和活動事務表 (ATT) 來追蹤需要恢復的內容。
1.2.2 重做階段（前滾）
系統會重播當機前未寫入磁碟的所有已提交交易。這確保所有已提交的變更都正確應用於資料庫檔案。
1.2.3 撤銷階段（回滾）
任何未提交的交易都會被回滾，以維護資料庫的一致性。一旦完成，資料庫即可用於正常操作。
1.3 常見症狀和錯誤訊息
當您的 SQL Server db 正在恢復，您通常會看到：
- 資料庫名稱顯示“（恢復中）” SQL Server 管理工作室
- 登入失敗並顯示“資料庫正在恢復”訊息
- 顯示恢復進度百分比的錯誤日誌條目
- 查詢時資料庫狀態顯示“RECOVERING”
2. 根本原因 SQL Server 恢復模式問題
2.1 不完整的還原操作
併購ost 常見原因發生在使用多個備份檔案還原時 無法恢復 沒有最終決定權的選項 恢復 命令。這將使資料庫等待其他復原操作。
2.2 交易日誌問題
大型事務日誌檔案或過多的虛擬日誌檔案 (VLF) 會顯著降低復原速度。當 MS SQL 資料庫復原時，如果 VLF 數量達到數千個，則復原過程可能需要數小時甚至數天才能完成。
2.3 系統相關問題
硬體故障、斷電或磁碟空間不足可能會中斷正常的資料庫操作，從而引發復原過程中漫長的復原過程。tart.
2.4 資料庫損壞
損壞的資料庫檔案會阻止復原成功完成，導致資料庫無限期地停留在復原模式。
3. 診斷ost修復前的步驟
3.1 檢查 SQL Server 錯誤日誌
在嘗試修復之前，請檢查 SQL Server 錯誤日誌中尋找恢復進度訊息。尋找顯示完成百分比和預計剩餘時間的條目。
- 未結案工單 SQL Server 管理工作室
- 前往 管理 -> SQL Server 日誌
- 查看資料庫名稱的最近條目
- 尋找恢復階段指標（第 1、2 或 3 階段，共 3 階段）
3.2 監測恢復進度
使用動態管理視圖來追蹤主動恢復操作：
SELECT session_id, command, blocking_session_id, wait_type, wait_time, wait_resource FROM sys.dm_exec_requests WHERE command = 'DB STARTUP';
3.3 檢查資料庫狀態
驗證目前資料庫狀態以了解復原狀態：
SELECT name, state_desc FROM sys.databases WHERE name = 'YourDatabaseName';
4. 修復＃1：等待自然恢復完成
有時，當你 SQL Server 資料庫正在復原中。當恢復過程正常進行但耗時超過預期時，此方法有效。
4.1 何時需要耐心
在以下情況下允許自然完成：
- 錯誤日誌顯示進度穩定，時間估計減少
- 沒有報告損壞錯誤
- 資料庫最近經歷了大量事務
- VLF 數量可控制（低於 1,000）
4.2 監測恢復進度
錯誤日誌中預估的恢復時間通常不準確。應關注進度百分比，而不是剩餘時間。具有大量事務歷史記錄的大型資料庫可能需要數小時才能完全復原。
5. 修復 #2：使用 RESTORE DATABASE WITH RECOVERY
此修復解決了遺漏了最後復原步驟的不完整還原操作。當您的 SQL Server 復原中的資料庫是使用 NORECOVERY 的還原過程所導致的。
5.1 理解命令
这 使用復原功能還原資料庫 命令透過回滾未提交的事務並使資料庫聯機來完成復原過程。
5.2 實施步驟
- 未結案工單 SQL Server 管理工作室
- 連接到您的 SQL Server 例
- 點擊 新建 > 使用目前連線進行查詢
- 執行：
RESTORE DATABASE [YourDatabaseName] WITH RECOVERY; - 等待完成確認
警告： 僅當您確定沒有其他待處理的復原作業時才使用此命令。
6. 修復 #3：解決交易日誌問題
交易日誌問題是導致復原時間延長的主要原因。此修復解決了日誌已滿、VLF 過多以及日誌空間不足的問題，這些問題會導致 SQL Server 在恢復中。
6.1 備份交易日誌
透過建立交易日誌備份釋放日誌空間：
- 未結案工單 SQL Server 管理工作室
- 右鍵單擊您的資料庫-> 任務 -> 備份
- 更改 備份類型 至 交易日誌
- 指定備份目標
- 點擊 OK 執行
6.2 管理虛擬日誌檔案（VLF）
使用以下方法檢查 VLF 計數：
DBCC LOGINFO('YourDatabaseName');
如果您有超過 1,000 個 VLF，請按以下方式減少它們：
- 備份交易日誌
- 縮小日誌檔：
DBCC SHRINKFILE(LogFileName, TRUNCATEONLY); - 以大塊（1GB 或更多）的方式增加日誌文件
6.3 安全地收縮日誌文件
僅在維護時段內沒有活動交易運行時收縮日誌。收縮作業前務必備份資料庫。
7. 修復 #4：執行 DBCC CHECKDB 並修復
資料庫損壞可能會導致復原無法成功完成。 DBCC CHECKDB 是一個內建指令，可辨識並修復導致 MS SQL 處於復原模式的輕微損壞問題。
7.1 檢查資料庫損壞
Start 使用標準方法來驗證資料庫完整性。首先直接嘗試 DBCC CHECKDB：
- 執行：
DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS; - 審查結果是否有一致性錯誤
- 記錄任何損壞訊息
如果 DBCC CHECKDB 失敗 如果出現類似「資料庫正在復原。正在等待復原完成」的錯誤，則表示資料庫正處於復原模式並阻止存取。在這種情況下，請繼續執行第 7.3 節以使用緊急模式。
7.2 可存取資料庫的修復選項
如果 DBCC CHECKDB 成功運作並發現損壞，請使用下列修復步驟：
- 將資料庫設定為單一使用者模式：
ALTER DATABASE [YourDatabaseName] SET SINGLE_USER; - 嘗試安全修復：
DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD); - 如果不成功，請使用：
DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS); - 返回多用戶：
ALTER DATABASE [YourDatabaseName] SET MULTI_USER;
7.3 資料庫無法存取時使用緊急模式
只有當資料庫卡在復原階段並拒絕正常的 DBCC CHECKDB 嘗試時，才需要緊急模式。此模式將資料庫標記為 READ_ONLY 並停用日誌記錄。當標準存取失敗時，請使用此方法：
- 設定緊急模式：
ALTER DATABASE [YourDatabaseName] SET EMERGENCY; - 設定單一用戶：
ALTER DATABASE [YourDatabaseName] SET SINGLE_USER; - 運行完整性檢查：
DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS; - 如果發現損壞，請先執行安全修復：
DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD); - 如果失敗，請使用資料遺失修復：
DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS); - 設定多用戶：
ALTER DATABASE [YourDatabaseName] SET MULTI_USER; - 設定在線：
ALTER DATABASE [YourDatabaseName] SET ONLINE;
重要事項： 緊急模式會繞過正常的復原過程，僅應在資料庫完全無法存取時使用。在升級到緊急模式之前，請務必先嘗試標準 DBCC CHECKDB 方法。
你可以找到 有關如何使用 DBCC CHECKDB 的更全面的指南.
8. 修復 #5：從備份恢復
當其他方法失敗或資料完整性受到質疑時，從乾淨的備份中復原通常是最有效的方法ost 可靠的解決方案 SQL Server 資料庫復原問題。
8.1 何時選擇備份恢復
在以下情況下考慮備份還原：
- 恢復已運作超過 24 小時，但無進展
- 損壞錯誤導致修復無法成功
- 您有最近已驗證的備份
- 自上次備份以來的資料遺失是可以接受的
8.2 逐步恢復過程
- 未結案工單 SQL Server 管理工作室
- 右鍵單擊 數據庫 -> 恢復數據庫
- 選擇 設備 在來源下
- 點擊 新增 並瀏覽到您的備份文件
- 選擇備份並點擊 OK
- 選擇 覆蓋現有資料庫 如果需要的話
- 點擊 OK 到tart 恢復
8.3 時間點恢復
為了最大限度地減少資料遺失，請使用交易日誌備份還原到特定時間點。確保從完整備份到所需還原點的日誌備份鏈完整無損。
8.4參考
您可以從我們的[網站地址]了解更多資訊。 備份和復原的全面指南 SQL Server 數據庫.
9. 修復 #6：停用 AUTO CLOSE 屬性
AUTO CLOSE 資料庫屬性可能會導致重複的復原循環，使您的 SQL Server 資料庫持續處於復原狀態。停用此屬性可解決此問題。
9.1 了解自動關閉問題
啟用自動關閉功能時， SQL Server 在最後一個連線結束後關閉資料庫，然後重新開啟資料庫以連接新的連線。這種重複的開啟操作每次都會觸發恢復過程。
9.2 禁用自動關閉
- 未結案工單 SQL Server 管理工作室
- 右鍵單擊您的資料庫-> 物業
- 選擇 選項 從左側面板
- 套裝 自動關閉 至 假
- 點擊 OK 應用程式變更
或者，使用 T-SQL：
ALTER DATABASE [YourDatabaseName] SET AUTO_CLOSE OFF;
10. 修復 #7：Restart SQL Server 私人訂製
服務資源tar它可以解決卡住的恢復過程，但應謹慎使用，因為它會tart 恢復。此修復適用於 SQL Server 在恢復過程中看起來完全凍結了。
10.1 服務恢復時tart 幫助
住宅tar在以下情況下使用該服務：
- 救援進程已停滯數小時
- 錯誤日誌顯示沒有新條目
- 其他資料庫運作正常
- 您可以承受延長停機時間
10.2 安全回應tar程序
- 未結案工單 SQL Server 配置管理器
- 前往 SQL Server 服務範圍
- 找到 SQL Server 您想要復原的實例tart，然後右鍵單擊 SQL Server （實例名稱）
- 選擇 住宅tart
- 等待服務完全恢復tart
- 監視錯誤日誌以了解復原進度
請注意： 住宅tarting 將導致恢復從 s 開始tart，可能會延長總恢復時間。
11. 修復 #8：透過分離並重新連接來修復資料庫
對於極端情況，請分開並重新連接資料庫：
- 分離資料庫：
EXEC sp_detach_db 'YourDatabaseName'; - 僅附加 MDF 文件：
CREATE DATABASE [YourDB] ON (FILENAME = 'C:\Path\YourDB.mdf') FOR ATTACH_REBUILD_LOG; - 這將重建一個新的交易日誌
警告： 此方法可能會導致資料遺失。僅在其他方法都無效時才使用。
12. 修正 #9：處理資料庫鏡像問題
資料庫鏡像配置可能會導致獨特的復原問題。此修復解決了特定於鏡像的問題，即使資料庫保持恢復狀態。
12.1 鏡像特定的恢復問題
由於夥伴連線問題或端點問題，鏡像資料庫可能會卡在復原過程中。主資料庫和鏡像資料庫都可以顯示復原狀態。
12.2 鏡像復原解決方案
住宅tart 鏡像端點：
- 尋找端點名稱：
SELECT * FROM sys.endpoints WHERE type = 4; - 停止端點：
ALTER ENDPOINT [EndpointName] STATE = STOPPED; - Start端點：
ALTER ENDPOINT [EndpointName] STATE = STARTED;
如果端點 restart 失敗，則中斷鏡像合作關係：
- 執行：
ALTER DATABASE [DatabaseName] SET PARTNER OFF; - 跑：
RESTORE DATABASE [DatabaseName] WITH RECOVERY; - 資料庫上線後重新配置鏡像
13. 修復 #10：使用專業恢復工具
內建第三方恢復工具可提供進階修復功能 SQL Server 方法失敗。這些工具通常可以從嚴重損壞的資料庫中復原資料。
13.1 DataNumen SQL Recovery
DataNumen SQL Recovery 具有較高的恢復率，並有全面的選擇。
以下是使用它的步驟：
- 停止 SQL Server 服務。
- 在復原模式下複製資料庫的文件，包括主 MDF 文件和輔助 NDF 文件。
- Starthe SQL Server 服務。
- Start DataNumen SQL Recovery.
- 選擇副本（而不是原始文件）作為要復原的資料庫的來源。
- 點擊“ Start 恢復”並依照指示恢復資料庫。
- 復原過程結束後，新的復原資料庫將出現在 SQL Server 其中包含所有恢復的資料。
13.2 何時考慮第三方工具
在以下情況下使用專業工具：
- 內建修復選項失敗或報告嚴重損壞
- 沒有可用的最新備份
- 儘管資料損壞，但必須恢復關鍵數據
- 標準恢復方法會導致大量資料遺失
14.預防最佳實踐
14.1 定期維護工作
實施這些做法以防止 SQL Server 資料庫復原問題：
- 安排定期完整備份和日誌備份： 維護完整的備份鏈
- 監測 VLF 計數： 將 VLF 保持在 100 以下以獲得最佳性能
- 規劃日誌檔案大小： 預先調整日誌大小以避免過度自動成長
- 運行常規 DBCC CHECKDB： 及早發現腐敗
14.2 監控和警報
設定主動監控：
- 配置資料庫狀態變更警報
- 監視日誌檔案磁碟機上的磁碟空間
- 追蹤長期運作的事務
- VLF 計數過高時發出警報
14.3 硬體和基礎設施
確保可靠的基礎設施：
15. 複雜場景故障排除
15.1 多個資料庫問題
當多個資料庫陷入復原狀態時：
- 檢查系統範圍的問題（磁碟空間、記憶體）
- 確定關鍵資料庫的復原優先級
- 考慮影響整個實例的硬體問題
- 查看最近的系統變更或更新
15.2 大型資料庫注意事項
對於超過 1TB 的資料庫：
- 預計恢復時間更長（可能需要幾天）
- 確保足夠的記憶體分配
- 考慮並行處理設置
- 在復原期間監視 tempdb 空間
15.3 何時聯絡 Microsoft 支持
聯絡 Microsoft 支援部門以取得以下資訊：
- 沒有備份選項的關鍵生產系統
- 嫌疑 SQL Server 軟件錯誤
- 需要保證恢復的企業環境
- 複雜的 Always On 或群集場景
16. 常見問題
Q：應該多長時間 SQL Server 資料庫復原通常需要多長時間？
答：復原時間取決於資料庫大小、交易量和硬體效能。小型資料庫通常只需幾分鐘即可恢復，而包含大量交易日誌的大型資料庫則可能需要數小時。錯誤日誌中顯示的預估時間通常不準確，因此請注意進度百分比。
Q：我可以停下來嗎 SQL Server 恢復期間不會遺失資料？
答：停止 SQL Server 在恢復期間通常是安全的，但會恢復tar從服務恢復時開始恢復過程tarts。這會延長總恢復時間，但不會導致原始事件期間發生的額外資料遺失。
Q：「恢復中」和「待恢復」有什麼區別？
答：「恢復中」是指 SQL Server 正在積極執行恢復操作。 「恢復待處理」表示恢復過程失敗tart，通常是由於檔案遺失、權限不足或磁碟空間問題造成的，必須先解決這些問題才能進行復原。
您可以在我們的[連結]中找到有關「待處理恢復」的更多詳細資訊。 綜合指南.
Q：如果我使用 REPAIR_ALLOW_DATA_LOSS，我會遺失資料嗎？
答：是的，REPAIR_ALLOW_DATA_LOSS 可能會移除損壞的資料以恢復資料庫一致性。請務必先嘗試 REPAIR_REBUILD，它可以修復結構問題而不會遺失資料。只有在沒有其他恢復選項的情況下，才將 REPAIR_ALLOW_DATA_LOSS 作為最後的手段。
Q：當一個資料庫處於復原狀態時，我可以存取其他資料庫嗎？
答：是的，同一伺服器上的其他資料庫 SQL Server 實例在恢復期間仍可存取。只有正在復原的資料庫不可用。但是，恢復操作可能會影響伺服器的整體效能。
Q：什麼原因導致資料庫陷入復原模式？
答：常見原因包括使用 NORECOVERY 的還原作業不完整、虛擬日誌檔案 (VLF) 過多、大量未提交交易、資料庫損壞、磁碟空間不足以及硬體問題。啟用 AUTO CLOSE 的資料庫也可能持續進入復原狀態。
Q：我如何知道恢復是否正在取得進展或陷入停滯？
A：監視器 SQL Server 錯誤日誌中顯示恢復進度訊息，顯示完成百分比。使用 sys.dm_exec_requests 檢查活動資料庫TARTUP 指令。如果百分比隨時間推移而增加，則表示恢復正在進行。幾個小時內沒有新的日誌條目可能表示進程卡住了。
Q：重新tart SQL Server 恢復期間的服務？
答：Restarting 是安全的，但應謹慎使用。它會tar從一開始就進行恢復，可能會使恢復時間加倍。只有tar如果恢復看起來完全凍結，並且幾個小時內沒有任何進展，或者您懷疑該過程確實卡住了。
Q：AUTO CLOSE 和恢復模式有什麼不同？
答：AUTO CLOSE 會在沒有連線時自動關閉資料庫，然後重新開啟資料庫以建立新連線。這種重複開啟的操作每次都會觸發短暫的復原過程，使資料庫看起來一直處於復原狀態。停用 AUTO CLOSE 可以解決此問題。
Q：交易日誌備份在復原過程中有幫助嗎？
答：如果日誌磁碟機已滿，交易日誌備份可以釋放日誌空間，從而可能允許復原繼續進行。但是，您無法備份目前處於復原模式的資料庫的日誌。日誌備份更適用於預防和ost-恢復維修。
Q：我應該何時聯絡 Microsoft 支援？
答：當您懷疑內建復原方法失敗時，請聯絡 Microsoft 支援部門 SQL Server 軟體錯誤，適用於複雜的 Always On 或叢集場景，或當企業環境需要以最少的停機時間保證資料恢復時。
Q：如何防止資料庫陷入復原狀態？
答：實施定期完整備份和日誌備份，監控和管理 VLF 計數，確保足夠的磁碟空間，使用正確的關機程序，維護硬體可靠性，在生產資料庫上停用 AUTO CLOSE，並運行定期 DBCC CHECKDB 作業以儘早發現損壞。
Q：什麼是 VLF？為什麼它們會影響恢復？
答：虛擬日誌檔案 (VLF) 是交易日誌檔案中的內部段。過多的 VLF（超過 1,000 個）會顯著降低恢復速度，因為 SQL Server 必須單獨處理每一個日誌檔。適當的日誌檔案大小和增長設定有助於維持最佳的 VLF 計數。
Q：資料庫正在復原時我可以從備份中復原嗎？
答：您無法復原目前處於復原模式的資料庫。您必須等待恢復完成，或停止 SQL Server 服務，或還原到其他資料庫名稱。緊急情況下，請考慮還原到新的資料庫名稱，然後在復原問題解決後重新命名。
17. 結論與後續步驟
17.1 主要解決方案總結
當您的 SQL Server 資料庫正在復原中，star按順序使用這些方法：
- 檢查錯誤日誌並監控進度
- 如果進展穩定，等待自然完成
- 使用 RESTORE WITH RECOVERY 進行不完整的恢復
- 解決交易日誌問題
- 執行 DBCC CHECKDB 或專業工具來檢查損壞情況
- 對於嚴重情況，請考慮備份恢復
Most SQL Server 使用這些經過驗證的方法，資料庫復原問題可在數小時內解決。對於複雜的情況，請毫不猶豫地使用先進的技術或專業的工具。
17.2 其他資源
如需進一步協助：
- Microsoft微軟 SQL Server 文档
- SQL Server 社區論壇
- 資料庫管理部落格和技術資源
- 專業資料庫復原服務
定期維護和監控可以防止ost 恢復問題。實施本指南中概述的預防措施，以最大限度地減少未來 MS SQL 復原問題的發生。
關於作者
元盛 是一位資深資料庫管理員 (DBA)，擁有超過 10 年的 SQL Server 環境和企業資料庫管理。他成功解決了金融服務、醫療保健和製造業等行業的數百個資料庫恢復場景。
袁專長於 SQL Server 資料庫復原、高可用性解決方案和效能優化。他擁有豐富的實務經驗，包括管理多TB資料庫、實施Always On可用性群組以及為關鍵業務系統開發自動備份和復原策略。
透過他的技術專長和實踐方法，袁致力於創建全面的指南，幫助資料庫管理員和 IT 專業人員解決複雜的 SQL Server 高效應對挑戰。他始終掌握最新 SQL Server 版本和微軟不斷發展的資料庫技術，定期測試恢復場景以確保他的建議反映現實世界的最佳實踐。
有關於的問題 SQL Server 恢復或需要額外的資料庫故障排除指導？袁歡迎 回饋和建議 用於改進這些技術資源。