譯者 | 李睿

審校 | 重樓

SQL Server數(shù)據(jù)庫偶爾會(huì)陷入“恢復(fù)中”（In Recovery）模式，這通常會(huì)讓數(shù)據(jù)庫管理員感到措手不及。這種狀態(tài)通常發(fā)生在數(shù)據(jù)庫重啟、恢復(fù)或意外關(guān)閉期間，因?yàn)镾QL Server需要重放或撤銷不完整的事務(wù)以保持?jǐn)?shù)據(jù)完整性。雖然這個(gè)過程通常是自動(dòng)執(zhí)行的，但有時(shí)可能會(huì)比預(yù)期花費(fèi)更長時(shí)間，甚至看起來停滯不前，這導(dǎo)致數(shù)據(jù)庫管理員不知所措。

如果遇到了這個(gè)問題，不要擔(dān)心。本文將幫助他們了解幕后發(fā)生的事情，并提供應(yīng)對策略。以下是需要了解的內(nèi)容：

• “恢復(fù)中”模式意味著什么——為什么數(shù)據(jù)庫會(huì)進(jìn)入這種狀態(tài)，以及SQL Server在后臺(tái)執(zhí)行的操作。
• SQL Server數(shù)據(jù)庫恢復(fù)的三個(gè)階段——詳細(xì)分析SQL Server在恢復(fù)過程中遵循的分析、重做和撤銷階段。
• 導(dǎo)致延遲的常見原因——從大型事務(wù)日志到過多的虛擬日志文件（VLF），查看可能減緩進(jìn)程的原因。
• 如何恢復(fù)在線狀態(tài)——學(xué)習(xí)將數(shù)據(jù)庫恢復(fù)到一致狀態(tài)的實(shí)用步驟，從等待到使用SQL修復(fù)工具。
• 何時(shí)尋求高級(jí)幫助——如果恢復(fù)過程看似停滯不前且沒有取得任何進(jìn)展，可以了解應(yīng)該怎么做。

通過閱讀這一指南，將全面了解SQL Server的恢復(fù)過程以及可用于盡快將數(shù)據(jù)庫恢復(fù)在線的工具。

理解SQL Server中的“正在恢復(fù)”模式

當(dāng)SQL Server重啟或從備份中恢復(fù)數(shù)據(jù)庫時(shí)將會(huì)進(jìn)入“恢復(fù)中”模式，以保持?jǐn)?shù)據(jù)的完整性。在這個(gè)階段，SQL Server重放或撤銷不完整的事務(wù)，以防止數(shù)據(jù)損壞并確保事務(wù)一致性。

在重啟SQL Server之后，數(shù)據(jù)庫進(jìn)入“恢復(fù)中”模式。SQL Server數(shù)據(jù)庫在啟動(dòng)時(shí)或從備份中恢復(fù)時(shí)也可能處在“恢復(fù)中”狀態(tài)。

圖1 SQL數(shù)據(jù)庫陷入“恢復(fù)中”模式

數(shù)據(jù)庫處在“正在恢復(fù)”狀態(tài)意味著正在執(zhí)行恢復(fù)過程，并在這一過程完成后自動(dòng)聯(lián)機(jī)。但是，可能會(huì)遇到恢復(fù)緩慢且數(shù)據(jù)庫陷入“恢復(fù)中”狀態(tài)。數(shù)據(jù)庫可能仍然處于恢復(fù)狀態(tài)，因?yàn)镾QL數(shù)據(jù)庫要經(jīng)歷三個(gè)恢復(fù)階段，而這一過程的恢復(fù)時(shí)間取決于數(shù)據(jù)庫文件的大小。

SQL數(shù)據(jù)庫恢復(fù)的三個(gè)階段

通常情況下，當(dāng)SQL Server重啟時(shí)數(shù)據(jù)庫沒有正確關(guān)閉時(shí)，它會(huì)進(jìn)行崩潰恢復(fù)，以確保數(shù)據(jù)庫保持一致。SQL數(shù)據(jù)庫需要經(jīng)歷三個(gè)恢復(fù)階段：

第一階段：分析

這個(gè)階段從“最后一個(gè)檢查點(diǎn)開始，直到事務(wù)日志結(jié)束”。它創(chuàng)建一個(gè)“臟頁表”（DPT）表，幫助確定崩潰時(shí)的所有“臟頁”。此外，它還創(chuàng)建一個(gè)“活動(dòng)事務(wù)表”（ATT）來標(biāo)識(shí)SQL Server停止時(shí)未提交的事務(wù)。

第二階段：重做

在這個(gè)階段，SQL Server會(huì)前滾在檢查點(diǎn)之后和崩潰之前發(fā)生的所有更改。實(shí)際上，在重做（Redo）階段，所有已經(jīng)提交但尚未通過檢查點(diǎn)寫入SQL數(shù)據(jù)文件（.mdf/.ldf）的事務(wù)都需要前滾。

第三階段：撤銷

如果在數(shù)據(jù)庫恢復(fù)時(shí)存在任何未提交的事務(wù)，則必須在撤消階段回滾這些事務(wù)，以使數(shù)據(jù)庫恢復(fù)到一致狀態(tài)。

如果數(shù)據(jù)庫陷入“恢復(fù)中”模式應(yīng)該怎么辦？

檢查SQL Server錯(cuò)誤日志，查看數(shù)據(jù)庫中可能類似以下內(nèi)容的第一條消息：

Starting up database ‘DatabaseName’

這意味著已經(jīng)打開數(shù)據(jù)庫文件，并且恢復(fù)過程已經(jīng)開始。在一段時(shí)間后，將會(huì)看到SQL Server正在經(jīng)歷三個(gè)恢復(fù)階段。如果正在尋找有關(guān)如何備份和恢復(fù)數(shù)據(jù)庫的指導(dǎo)，可以查看有關(guān)備份和恢復(fù)Azure SQL數(shù)據(jù)庫的指南。

數(shù)據(jù)庫恢復(fù)的第一階段如下所示：

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數(shù)據(jù)庫將會(huì)繼續(xù)執(zhí)行恢復(fù)流程的第二和第三階段。

 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.

一旦第二階段和第三階段完成，將會(huì)看到類似以下的信息：

 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.

在錯(cuò)誤日志中，注意“不需要用戶操作”的消息，這表明數(shù)據(jù)庫處于恢復(fù)狀態(tài)。但是，恢復(fù)可能需要比預(yù)期更長的時(shí)間，導(dǎo)致數(shù)據(jù)庫一直陷入“恢復(fù)中”模式中。

SQL數(shù)據(jù)庫陷入“恢復(fù)中”模式的原因

以下是可能導(dǎo)致SQL數(shù)據(jù)庫陷入“恢復(fù)中”模式的一些原因：

• 長時(shí)間運(yùn)行的事務(wù)正在回滾
• 事務(wù)日志文件非常大
• 數(shù)據(jù)庫事務(wù)日志中包含過多的虛擬日志文件（VLF）
• SQL Server存在bug，現(xiàn)在已經(jīng)修復(fù)。

如何使數(shù)據(jù)庫恢復(fù)到一致狀態(tài)？

解決方法1：等待數(shù)據(jù)庫恢復(fù)完成

使數(shù)據(jù)庫重新聯(lián)機(jī)的最直觀的解決方案是耐心等待恢復(fù)過程完成；這可能需要幾個(gè)小時(shí)或幾天的時(shí)間。如果SQL Server 2008或SQL Server 2008 R2中的數(shù)據(jù)庫恢復(fù)時(shí)間比預(yù)期的長，那么應(yīng)用Microsoft修復(fù)程序可能會(huì)有所幫助。

注：避免運(yùn)行RESTORE命令使數(shù)據(jù)庫處于一致狀態(tài)，因?yàn)镾QL Server已經(jīng)在嘗試執(zhí)行相同的任務(wù)。然后，運(yùn)行“RESTORE with..Recovery”意味著讓數(shù)據(jù)庫再次執(zhí)行相同的步驟。

解決方案2：使用專業(yè)的SQL數(shù)據(jù)庫修復(fù)工具

如果恢復(fù)過程完成，但未能將數(shù)據(jù)庫恢復(fù)到一致狀態(tài)，則使用專門的SQL修復(fù)工具可以幫助將數(shù)據(jù)庫恢復(fù)到原始狀態(tài)。

• Stellar Repair for MS SQL——這款專業(yè)的工具可以幫助在SQL數(shù)據(jù)庫損壞或發(fā)生故障后將其恢復(fù)到原始狀態(tài)。
• ApexSQL Recover——這款工具可以恢復(fù)已經(jīng)刪除、截?cái)嗷驌p壞的SQL Server數(shù)據(jù)庫中的數(shù)據(jù)。
• dbForge SQL Complete——雖然它主要是一款I(lǐng)DE擴(kuò)展工具，但它提供了有用的錯(cuò)誤處理和故障排除功能。
• Redgate SQL Data Recovery——Redgate提供了一系列SQL Server工具，包括數(shù)據(jù)恢復(fù)功能。
• SysTools SQL Recovery Tool——這款工具可恢復(fù)損壞的SQL數(shù)據(jù)庫文件（.MDF和.NDF）到可用狀態(tài)。
• Kernel for SQL Database Recovery——這款工具可以從損壞和意外關(guān)閉的情況中恢復(fù)和還原SQL Server數(shù)據(jù)庫。
• Aryson SQL Database Recovery——這款工具可以修復(fù)和還原SQL Server中的MDF和NDF文件。

結(jié)論

本文介紹了SQL數(shù)據(jù)庫陷入“恢復(fù)中”模式時(shí)的含義、恢復(fù)的三個(gè)關(guān)鍵階段（（分析、重做和撤消），以及如何使數(shù)據(jù)庫重新聯(lián)機(jī)。此外還討論了可能的原因，從大型事務(wù)日志到過多的虛擬日志文件（VLF）。

如果SQL數(shù)據(jù)庫仍然陷入“在恢復(fù)中”模式，至關(guān)重要的是要保持耐心。避免運(yùn)行RESTORE命令，因?yàn)檫@會(huì)重新啟動(dòng)恢復(fù)過程。至于那些無法通過人工干預(yù)解決的嚴(yán)重問題，可以考慮使用專業(yè)的SQL數(shù)據(jù)庫修復(fù)工具來恢復(fù)數(shù)據(jù)。

原文標(biāo)題：How to Fix SQL Database Stuck in Recovery Mode，作者：Daniel Calbimonte