A database that shows In Recovery is running crash recovery, the normal process SQL Server uses after a restart to make the database consistent. In most cases the fix is to wait, since it comes back online on its own. The SQL Server error log shows the percent complete and the seconds remaining, and you should never restart the service to hurry it, because that starts recovery over. When recovery never finishes because the file itself is damaged, Univik reads the MDF directly, which the SQL Database Recovery tool handles.
You restart a SQL Server, or it reboots on its own, and a database sits there marked In Recovery. The application cannot reach it, and every refresh of Object Explorer shows the same status. The instinct is to do something, restart again, run a command, anything. For a genuinely recovering database the right move is the hardest one, wait and watch the progress. Here is what the state means, how to read how far along it is and the one action that turns a short wait into a long one.
What “In Recovery” Actually Means
In Recovery is not an error. It is SQL Server doing its job. When the service starts, every database runs a recovery process that replays and rolls back transactions from the log so the data ends up consistent, exactly as it was before the shutdown. While that runs, the database is off limits and shows In Recovery, and the moment it finishes the database comes online by itself. No command brings it back faster, and none is needed.
Try to query the database while this runs and SQL Server replies that the database is being recovered and to wait until recovery is finished, the message most people arrive here searching for. To confirm the exact state, run a quick check of sys.databases and read the state_desc column. RECOVERING means recovery is running, while RECOVERY_PENDING and SUSPECT are the states that need action instead.
The trap is confusing this running state with the states that look similar but need action. A database stuck in Recovery Pending never started recovery, blocked by a file it cannot reach, and the recovery pending guide covers that fix. A Suspect database hit corruption during recovery, handled in the suspect database guide. A database showing Restoring is waiting to finish a restore, covered in the restore from a BAK file guide. In Recovery is the one that fixes itself.
The Three Phases Behind the Wait
Recovery works through three phases in order, and knowing them tells you why the wait can be long. Analysis reads the transaction log forward from the last checkpoint and sorts every open transaction into two piles, the ones committed to the log but not yet written to the data file, and the ones that were still open. Redo, the roll forward phase, replays that first pile so the committed work is saved. Undo, the roll back phase, reverses the second pile so half done work disappears.
On SQL Server Enterprise edition, a feature called Fast Recovery brings the database online after the redo phase while undo is still running in the background, so users get in sooner. On Standard edition the database stays offline until all three phases finish. That single edition difference is why the same crash can strand one server for seconds and another for minutes.
See the Recovery Progress in the Error Log
You are not flying blind while a database recovers. SQL Server writes its progress to the error log as it goes, with a percent complete and an estimate of the time left. Checking it takes four steps.
- Open the SQL Server error log in SSMS under Management, or run
sp_readerrorlog. - Find the newest line naming your database with a percent complete figure.
- Note the phase it lists, analysis, redo or undo, along with the seconds it says remain.
- Look again after a minute, and if the percent has climbed and the time has dropped, recovery is moving, so let it run.
-- recovery progress is written to the error log, newest entries last
EXEC sp_readerrorlog;
-- the line you are looking for reads like this
-- Recovery of database 'Sales' is 62% complete (approximately 140 seconds remain). Phase 2 of 3.
-- a rolling back session reports the same progress here
SELECT session_id, command, percent_complete, estimated_completion_time
FROM sys.dm_exec_requests
WHERE percent_complete > 0;The percent complete and the estimated time in sys.dm_exec_requests match what the error log shows, so use whichever is easier to watch. Both give you the one thing you actually need, evidence that the number is moving.
When recovery finishes, the log writes one last line that splits the total time across the three phases, analysis, redo and undo, each timed on its own. If undo owns most of it, a large rollback was the slow part, which points straight at the transaction to watch for next time.
How Long a Recovery Takes
There is no fixed answer, because recovery time tracks the work in the log, not the size of the database. A quiet database that was shut down cleanly recovers in seconds. The long waits come from the undo phase, when a large transaction was open at the moment of the crash and every change it made has to be rolled back. Rolling back a delete that touched millions of rows can take as long as the delete itself, sometimes longer, and there is no shortcut through it.
A killed transaction behaves the same way. If someone cancelled a huge update and the session shows as rolling back, that rollback runs on the same machinery as crash recovery and cannot be rushed. The size of the transaction sets the clock. This is the real reason a recovery drags, and it is also the problem that Accelerated Database Recovery was built to remove.
Why Restarting Makes It Worse
Here is the mistake that turns a fifteen minute wait into an hour. A database is grinding through recovery, someone loses patience and restarts the SQL Server service to give it a push. Recovery does not pick up where it left off. It starts over from the beginning, running analysis, redo and undo again on the same log. Every second of progress is thrown away, and the clock resets.
The same logic applies to a session stuck in rollback. Killing the connection again does nothing, and bouncing the service only makes SQL Server redo the rollback from scratch on restart. When a database is genuinely recovering, the fastest path to online is to leave it alone. Restarting feels like action, but it is the one move that reliably makes the wait longer.
Tell a Slow Recovery from a Stuck One
Waiting is right when recovery is working, but a real hang deserves a closer look, and the error log tells the two apart. A healthy recovery shows a percent that climbs and an estimate that falls each time you check, even if slowly. That is a long job, not a broken one. Let it finish.
Worry when the percent sits at the same number across several checks with no movement, or when the log stops writing recovery lines entirely and no error follows. A recovery that is truly stuck has a cause underneath, a failing disk, a full drive that leaves the log no room to work, or corruption that recovery cannot get past. At that point the database may fall into Suspect, and the suspect database guide takes over. A log that has grown unmanageable is its own topic, covered in the shrink the LDF file guide, and the read the transaction log guide explains what the engine is chewing through.
Make Recovery Faster with ADR
If long recoveries are a recurring pain, SQL Server 2019 added the lasting fix. Accelerated Database Recovery keeps a persistent version store inside the database, a record of prior row versions that survives a restart, so undo no longer has to scan the whole log to reverse an open transaction. It reverts rows from the version store instead, which makes rollback and crash recovery close to instant no matter how large the transaction was.
You turn it on per database with a single statement.
ALTER DATABASE Sales SET ACCELERATED_DATABASE_RECOVERY = ON;Microsoft’s own testing shows a database that took over three minutes to recover coming online in about ten seconds with the feature on, because recovery time stops depending on the length of the longest transaction. The feature landed in SQL Server 2019 and each version since has sharpened it, and Azure SQL Database has it enabled by default. For a server that keeps getting caught by long rollbacks, this is the setting to change. Read the ADR concepts reference before enabling it widely, since the version store uses space in the database.
When the Database Is Not Really Recovering
Waiting only pays off when recovery is actually making progress. Sometimes it never will. If the MDF or the log is corrupt, recovery can loop or stall and the database drops into Suspect, and no amount of patience finishes the job. The causes of SQL Server corruption guide covers how it gets there.
When recovery cannot complete because the file is damaged, the data can still be read outside the engine even though SQL Server cannot bring it online. Univik opens the MDF at the page level with no instance involved and pulls the tables out, which sidesteps the recovery process entirely. Repair the file with SQL Database Recovery, view it in place with the free MDF viewer, or take the broader route to opening an MDF without SQL Server. For a database that is simply recovering, though, none of that is needed. Let it run.
Recovery that never finishes?
When the file is too damaged for recovery to complete and the database drops into Suspect, Univik opens the MDF directly on disk and lifts the tables out, no instance required.
Recover the MDF Instead
Frequently Asked Questions
How Long Does a SQL Server Database Stay in Recovery?
Anywhere from a few seconds to a few hours, because recovery time depends on the work in the transaction log, not the size of the database. A clean shutdown recovers fast. A large transaction that was open at the crash has to be rolled back, which can take as long as the original operation. Read the error log for the percent complete and the estimated seconds remaining to see where yours stands.
How do I Check the Recovery Percentage?
Open the SQL Server error log, either in SSMS under Management or with sp_readerrorlog, then find the newest line for your database that reads recovery is a percent complete with a phase and seconds remaining. You can also query sys.dm_exec_requests and read the percent_complete and estimated_completion_time columns for the recovery session. Both report the same progress, so watch whichever is easier.
Can I Force a Database out of Recovery Mode?
Not safely, and you rarely need to. A database that is genuinely recovering comes online on its own once the process finishes, so the right move is to wait and watch the percent climb. If the state is really Recovery Pending and not a running recovery, the fix is a different one. Forcing or restarting only restarts recovery from the beginning.
Why Is My Database in Recovery after a Restart?
Because that is normal. Every time the SQL Server service starts, each database runs crash recovery to replay and roll back transactions from the log and reach a consistent state. If the last shutdown was clean it finishes in seconds. If a large transaction was open when the server stopped, the roll back takes longer and the database shows In Recovery until it completes.
Does Restarting SQL Server Help a Stuck Recovery?
No, it makes things worse. Restarting the service does not resume recovery where it left off, it starts the whole process over from the beginning, discarding every second of progress. The same is true for a session stuck rolling back. When a database is recovering, leaving it alone is the fastest path to online.
What Is Accelerated Database Recovery?
Accelerated Database Recovery, added in SQL Server 2019, is a feature that makes recovery and rollback close to instant by keeping a persistent version store inside the database. Undo reverts rows from that store instead of scanning the whole log, so recovery time no longer depends on the size of the open transaction. Enable it per database with ALTER DATABASE and SET ACCELERATED_DATABASE_RECOVERY = ON.