When your SQL database hits RECOVERY PENDING mode, don’t panic.
This status means recovery is stuck, not failed. To fix this, you need to find the root cause. It could be anything from adding more disk space to fixing or rebuilding database files.
Taking these steps can help restore your database to full functionality. This will ensure minimal downtime and protect data integrity.
SQL Server RECOVERY PENDING: What Does This Status Mean?
This means the database ran into a problem.
SQL Server knows it needs to run a recovery process on the database. However, something is stopping this process from running.
SQL Server doesn’t know if the recovery will fail. The recovery process just hasn’t started yet.
RECOVERY PENDING – the good news
The database is likely OK. It is less likely that it is damaged.
So don’t panic yet.
Be aware that the database will not be available to users. You will need to fix the error before bringing it back online.
How do you check the database state?
Microsoft SQL Server Databases are always in one specific state.
Possible database states are:
- ONLINE
- RESTORING
- RECOVERING
- RECOVERY PENDING
- SUSPECT
- EMERGENCY
- OFFLINE
- COPYING
- OFFLINE SECONDARY
Run this query below and check the current state of your database:
SELECT name
,state_desc
FROM sys.databases

Reasons why SQL Server Database state is in RECOVERY PENDING
There can be many. But here are a few I have seen:
- SQL Server shut down due to failure. It could be hardware, power, or something else.
- The disk could be missing.
- MDF or LDF files might be missing.
- The disk drive is full.
- SQL Upgrade didn’t go well or was interrupted.
- Big changes were being made, and something failed in the middle. This could include changes to the FILESTREAM feature.
- The LDF (log) file has been corrupted.
- The MDF database file can become corrupted for many reasons. It could be due to disk or SAN issues, hardware faults, viruses, or other problems.
- The server restarted, and something changed. The disk or directory might be missing, or there could be a permissions issue.
- Cryptoware has encrypted your SQL files.
What are the ways to fix the RECOVERY PENDING state?
Before starting any repair process, ensure you have sufficient backups of the database.
Start with looking at the SQL Server error log.
Is there anything that stands out and explains why DB is stuck?
If not, the next step is to check the Windows Event Viewer. Look for anything unusual or that stands out.
Method 1. How to fix RECOVERY PENDING mode – Set database state to ONLINE
If the DB recovery can’t start because there’s not enough disk space, follow these steps. This is a common issue:
- Increase the disk space
- Set the DB to ONLINE mode
- Run
CHECKDB, but do not use the REPAIR option!
You can also execute the following script:
ALTER DATABASE ‘AdventureWorks2019’
SET ONLINE;
DBCC CHECKDB (‘AdventureWorks2019’)
WITH NO_INFOMSGS;If the command completed without warnings, the database should now be in the ONLINE state, which is the desired outcome.
You don’t need to repair the DB.
Method 2. How to fix RECOVERY PENDING mode – Rebuilding log files in EMERGENCY mode
If the SQL error log shows that the database hasn’t recovered because the log file is missing, deleted, renamed, or corrupted, follow these steps:
- First, set the database to EMERGENCY mode
- Detach the database (take it OFFLINE)
- Re-attach it (bring it ONLINE)
Here is the T-SQL script that does all those steps:
ALTER DATABASE AdventureWorks2019
SET SINGLE_USER;
GO
DBCC CHECKDB (
AdventureWorks2019
,REPAIR_REBUILD
)
WITH NO_INFOMSGS
,ALL_ERRORMSGS;
GO
ALTER DATABASE [AdventureWorks2019]
SET ONLINE;
GO
ALTER DATABASE [AdventureWorks2019]
SET MULTI_USER;
GOThe system will automatically remove the corrupt logs and will build a new one.
Method 3. How to fix RECOVERY PENDING mode – Start DBCC CHECKDB with REPAIR Option
If the above doesn’t work, the next step is to perform a ‘repair’.
Make sure you have a backup. Don’t do this on the DB which is the ONLY version DB you have, as after repair is complete, you may lose data and you may not like what got lost!
I only recommend the REPAIR option as a last resort. Microsoft recommends restoring from the last known good backup as the primary method for recovering from errors reported by DBCC CHECKDB.
The DBCC CHECKDB with the REPAIR option is a logged and recoverable transaction.
What does that mean to you?
It means if you wrap DBCC CHECKDB with REPAIR into a transaction (execute BEGIN TRANSACTION before running the command) and you don’t like the final result, you can roll the transaction back and get back to where you started.
That way you will be able to ROLLBACK the repair operations if necessary.
There are different repair levels. Start with REPAIR_REBUILD, which performs repairs that have no data loss:
- Set the database to single-user mode
- Run
DBBC CHECKDBwithREPAIR_REBUILD - Set the database to ONLINE and re-activate multiple user mode
Here is the T-SQL script below on how to do it:
ALTER DATABASE AdventureWorks2019
SET SINGLE_USER;
GO
DBCC CHECKDB (
AdventureWorks2019
,REPAIR_REBUILD
)
WITH NO_INFOMSGS
,ALL_ERRORMSGS;
GO
ALTER DATABASE [AdventureWorks2019]
SET ONLINE;
GO
ALTER DATABASE [AdventureWorks2019]
SET MULTI_USER;
GOIf the repair is successful, the database can go online.
If not, DBCC with REPAIR_ALLOW_DATA_LOSS is your next option.
This may result in a loss of data!
Again, make sure that you have backups and you understand the risks involved.
Here are the steps:
- Set the database to EMERGENCY mode
- Run
DBBC CHECKDBwith REPAIR_ALLOW_DATA_LOSS - Set the database to ONLINE and set it to multi-user mode
Here is the T-SQL script below:
ALTER DATABASE [DATABASENAME]
SET EMERGENCY;
GO
ALTER DATABASE [DATABASENAME]
SET SINGLE_USER;
GO
DBCC CHECKDB (
DATABASENAME
,REPAIR_ALLOW_DATA_LOSS
)
WITH NO_INFOMSGS
,ALL_ERRORMSGS;
GO
ALTER DATABASE [DATABASENAME]
SET ONLINE;
GO
ALTER DATABASE [DATABASENAME]
SET MULTI_USER;
GOReferences
Speak with a SQL Expert
In just 30 minutes, we will show you how we can eliminate your SQL Server headaches and provide operational peace of mind
