譯者 | 李睿
審校 | 重樓
SQL Server數據庫偶爾會陷入“恢復中”(In Recovery)模式,這通常會讓數據庫管理員感到措手不及。這種狀態通常發生在數據庫重啟、恢復或意外關閉期間,因為SQL Server需要重放或撤銷不完整的事務以保持數據完整性。雖然這個過程通常是自動執行的,但有時可能會比預期花費更長時間,甚至看起來停滯不前,這導致數據庫管理員不知所措。
如果遇到了這個問題,不要擔心。本文將幫助他們了解幕后發生的事情,并提供應對策略。以下是需要了解的內容:
- “恢復中”模式意味著什么——為什么數據庫會進入這種狀態,以及SQL Server在后臺執行的操作。
- SQL Server數據庫恢復的三個階段——詳細分析SQL Server在恢復過程中遵循的分析、重做和撤銷階段。
- 導致延遲的常見原因——從大型事務日志到過多的虛擬日志文件(VLF),查看可能減緩進程的原因。
- 如何恢復在線狀態——學習將數據庫恢復到一致狀態的實用步驟,從等待到使用SQL修復工具。
- 何時尋求高級幫助——如果恢復過程看似停滯不前且沒有取得任何進展,可以了解應該怎么做。
通過閱讀這一指南,將全面了解SQL Server的恢復過程以及可用于盡快將數據庫恢復在線的工具。
理解SQL Server中的“正在恢復”模式
當SQL Server重啟或從備份中恢復數據庫時將會進入“恢復中”模式,以保持數據的完整性。在這個階段,SQL Server重放或撤銷不完整的事務,以防止數據損壞并確保事務一致性。
在重啟SQL Server之后,數據庫進入“恢復中”模式。SQL Server數據庫在啟動時或從備份中恢復時也可能處在“恢復中”狀態。
圖1 SQL數據庫陷入“恢復中”模式
數據庫處在“正在恢復”狀態意味著正在執行恢復過程,并在這一過程完成后自動聯機。但是,可能會遇到恢復緩慢且數據庫陷入“恢復中”狀態。數據庫可能仍然處于恢復狀態,因為SQL數據庫要經歷三個恢復階段,而這一過程的恢復時間取決于數據庫文件的大小。
SQL數據庫恢復的三個階段
通常情況下,當SQL Server重啟時數據庫沒有正確關閉時,它會進行崩潰恢復,以確保數據庫保持一致。SQL數據庫需要經歷三個恢復階段:
第一階段:分析
這個階段從“最后一個檢查點開始,直到事務日志結束”。它創建一個“臟頁表”(DPT)表,幫助確定崩潰時的所有“臟頁”。此外,它還創建一個“活動事務表”(ATT)來標識SQL Server停止時未提交的事務。
第二階段:重做
在這個階段,SQL Server會前滾在檢查點之后和崩潰之前發生的所有更改。實際上,在重做(Redo)階段,所有已經提交但尚未通過檢查點寫入SQL數據文件(.mdf/.ldf)的事務都需要前滾。
第三階段:撤銷
如果在數據庫恢復時存在任何未提交的事務,則必須在撤消階段回滾這些事務,以使數據庫恢復到一致狀態。
如果數據庫陷入“恢復中”模式應該怎么辦?
檢查SQL Server錯誤日志,查看數據庫中可能類似以下內容的第一條消息:
Starting up database ‘DatabaseName’這意味著已經打開數據庫文件,并且恢復過程已經開始。在一段時間后,將會看到SQL Server正在經歷三個恢復階段。如果正在尋找有關如何備份和恢復數據庫的指導,可以查看有關備份和恢復Azure SQL數據庫的指南。
數據庫恢復的第一階段如下所示:
Plain Text
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.在第一階段完成炎后,SQL Server數據庫將會繼續執行恢復流程的第二和第三階段。
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.一旦第二階段和第三階段完成,將會看到類似以下的信息:
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存在bug,現在已經修復。
如何使數據庫恢復到一致狀態?
解決方法1:等待數據庫恢復完成
使數據庫重新聯機的最直觀的解決方案是耐心等待恢復過程完成;這可能需要幾個小時或幾天的時間。如果SQL Server 2008或SQL Server 2008 R2中的數據庫恢復時間比預期的長,那么應用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數據庫修復工具來恢復數據。
原文標題:How to Fix SQL Database Stuck in Recovery Mode,作者:Daniel Calbimonte























