How to Fix SQL Server Recovery Pending Mode

What SQL Server Recovery Pending Means

A database in Recovery Pending hit a resource-related error during recovery and needs manual intervention before recovery can finish. It is different from the other states you might see:

• RECOVERING is the normal, temporary “recovery is running” state. It moves to ONLINE on its own when recovery succeeds.
• RECOVERY PENDING means recovery could not even start because of a missing or inaccessible resource. The database is not necessarily damaged.
• SUSPECT is more serious. At least the primary filegroup is suspect and may be damaged.

The good news: a Recovery Pending database is usually fine. The data is probably intact, you just need to clear whatever is blocking recovery. The database will not be available to users until you do.

How to Check the Database State

Every SQL Server database is always in one specific state. You can read it from sys.databases:

USE master;
GO
SELECT name, state_desc, user_access_desc, recovery_model_desc
FROM sys.databases
WHERE name = N'YourDatabase';
GO

Note: on SQL Server 2022 and later, reading the error log with sp_readerrorlog requires the VIEW ANY ERROR LOG permission (on 2019 and earlier it was VIEW SERVER STATE).

Why a SQL Server Database Goes Into Recovery Pending

Common root causes include:

• SQL Server shut down unexpectedly (hardware, power, or a crash).
• A data (.mdf/.ndf) or log (.ldf) file is missing, renamed, or moved.
• The transaction log file is corrupted.
• The disk holding the files is missing, offline, or full.
• The SQL Server service account lost permission to the files (often after a server or directory change).
• An upgrade was interrupted partway through.
• Ransomware encrypted the database files.

A note on terminology: when the log fills *during* recovery, Microsoft’s Error 9002 documentation describes the state as RESOURCE PENDING, while the database-states page documents RECOVERY PENDING. Either way, disk or log exhaustion during recovery is a real cause. Read the error log for the exact message.

How to Fix SQL Server Recovery Pending: The Safe Order

The order matters. Diagnose first, fix the cause, try a clean restart, restore from backup before any repair, and treat emergency-mode repair as the last resort. This order has not changed in SQL Server 2025.

Step 1: Read the SQL Server Error Log

Start here. The error log almost always names the real problem, a missing file, a permission failure, or a resource shortage.

-- Current error log, filtered to your database name:
EXEC sys.sp_readerrorlog 0, 1, N'YourDatabase';
GO

If nothing stands out, check the Windows Event Viewer next.

Step 2: Fix the Root Cause

Fix whatever the log points to. In practice that usually means restoring access to a missing data or log file, correcting the SQL Server service account’s permissions on the file path, or freeing disk space.

Step 3: Try to Bring the Database Online

If the cause is corrected and the database should be recoverable, try the least destructive restart. Run this in auto-commit mode, not inside an explicit transaction:

USE master;
GO
ALTER DATABASE [YourDatabase] SET ONLINE;
GO

If it completes without errors, the database is back ONLINE and you are done. You do not need to repair anything.

Step 4: Restore From Backup (the Primary Fix)

If the database still will not recover, restore from your last known-good backup. This is Microsoft’s primary recovery method, and it is safer than any repair. If the database is still partially accessible, take a tail-log backup first so you lose as little as possible.

-- Tail-log backup (database online, about to restore):
BACKUP LOG [YourDatabase] TO DISK = N'X:\Backups\tail.trn' WITH NORECOVERY;
GO

-- Restore full, then differential, then logs in order. Recover only at the end:
RESTORE DATABASE [YourDatabase] FROM DISK = N'X:\Backups\full.bak'  WITH NORECOVERY;
RESTORE DATABASE [YourDatabase] FROM DISK = N'X:\Backups\diff.bak'  WITH NORECOVERY;
RESTORE LOG      [YourDatabase] FROM DISK = N'X:\Backups\log_1.trn' WITH NORECOVERY;
RESTORE LOG      [YourDatabase] FROM DISK = N'X:\Backups\log_2.trn' WITH NORECOVERY;
RESTORE DATABASE [YourDatabase] WITH RECOVERY;
GO

If you only have the log file and the database is damaged but the log is intact, use WITH NO_TRUNCATE instead of WITH NORECOVERY on the tail-log backup. For a point-in-time recovery, add STOPAT = 'YYYY-MM-DDThh:mm:ss' to each RESTORE LOG.

Step 5: Last Resort, Emergency Mode and DBCC CHECKDB Repair

Only if restore is impossible should you repair. A few facts worth being precise about, because bad advice here loses data:

• Any REPAIR option requires the database in SINGLE_USER mode.
• A normal REPAIR_REBUILD runs logged inside a user transaction, so you can wrap it in BEGIN TRANSACTION and ROLLBACK if you do not like the result.
• Emergency-mode repair is different. You cannot run DBCC CHECKDB in emergency mode inside a user transaction and roll it back, and REPAIR_ALLOW_DATA_LOSS deletes data to reach physical consistency. It is irreversible.
• After any emergency repair, the database can still hold transactional inconsistencies. Run DBCC CHECKCONSTRAINTS and take a fresh full backup immediately.

USE master;
GO
ALTER DATABASE [YourDatabase] SET EMERGENCY;
ALTER DATABASE [YourDatabase] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB (N'YourDatabase', REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS, NO_INFOMSGS;
ALTER DATABASE [YourDatabase] SET MULTI_USER;
DBCC CHECKCONSTRAINTS (N'YourDatabase') WITH ALL_CONSTRAINTS;
BACKUP DATABASE [YourDatabase] TO DISK = N'X:\Backups\post_repair_full.bak' WITH INIT, CHECKSUM;
GO

REPAIR_FAST is obsolete. It is kept only for backward compatibility and performs no repair actions, so ignore any older guidance that recommends it. If you reach this step and the data matters, this is the moment to bring in help. Our emergency SQL Server recovery work shows what is possible even when backups are missing.

Rebuilding a Missing Transaction Log

If the error log shows the database cannot recover because the log file is missing or corrupt, you may be tempted to “just rebuild the log.” Be careful: detaching a database (sp_detach_db) and taking it offline (ALTER DATABASE ... SET OFFLINE) are not the same operation, and rebuilding a log only works under strict conditions.

The supported path is CREATE DATABASE ... FOR ATTACH_REBUILD_LOG, and it requires that the database was cleanly shut down and that all data files (.mdf and .ndf) are present. If a log file is missing, SQL Server creates a new 1 MB log. This breaks the log backup chain, so take a full backup immediately afterward. If the shutdown was not clean, this path will not work, and you should go back to restoring from backup.

USE master;
GO
CREATE DATABASE [YourDatabase]
ON (FILENAME = N'X:\Data\YourDatabase.mdf'),
   (FILENAME = N'X:\Data\YourDatabase_2.ndf')
FOR ATTACH_REBUILD_LOG;
GO

Treat this as a controlled salvage operation, not a routine fix. The older undocumented log-rebuild tricks are not safe recommendations in 2026. And before you restart a server mid-incident, remember that restarting SQL Server can destroy the evidence you need to find the real cause.

Does SQL Server 2025 Change This?

The honest answer: the fix itself has not changed. As of SQL Server 2025 (17.x), there is no new database state, no changed definition of Recovery Pending, and no new repair-first workflow. The guidance is still read the error log, fix the root cause, restart, and restore before you repair. (For everything new in the release itself, see our SQL Server 2025 overview. This section only covers what touches recovery.)

What has moved in the 2025 era is adjacent, and mostly preventive:

• Accelerated Database Recovery (ADR) was introduced in 2019 and improved in 2022 and 2025. It makes crash recovery and long rollbacks far faster, which can shorten the window where a database is stuck recovering. It is still off by default on on-premises SQL Server and always on in Azure SQL Database and Managed Instance.
• ADR in tempdb is new in 2025. You can now set ACCELERATED_DATABASE_RECOVERY = ON for tempdb, which earlier versions did not allow. It needs an engine restart to take effect.
• tempdb space resource governance is new in 2025. It caps tempdb consumption per workload group, which helps prevent a runaway query from exhausting tempdb, one of the resource-driven causes of startup trouble.

Recovery Pending on Azure SQL and Amazon RDS

The on-premises playbook (fix file permissions, rebuild the log, detach and attach, emergency-mode repair) largely does not apply on managed platforms. Use the platform’s restore tooling instead.

• Azure SQL Database: you have no instance or file access. Recovery is a service operation, so use point-in-time restore, deleted-database restore, long-term-retention restore, or geo-restore. Restores create a new database; you cannot overwrite in place.
• Azure SQL Managed Instance: closer to SQL Server, but EMERGENCY, OFFLINE, SINGLE_USER, and RESTRICTED_USER cannot be set, and DBCC CHECKDB REPAIR options cannot be used because the database cannot be put in single-user mode. Use point-in-time restore, geo-restore, or native restore from URL, and escalate suspected corruption to Azure support. ADR is always on.
• Amazon RDS for SQL Server: no host access and no sysadmin role. You bring a database online with rdsadmin.dbo.rds_set_database_online, not plain ALTER DATABASE ... SET ONLINE. Recover via instance point-in-time restore, snapshots, or native S3 backup and restore, and escalate to AWS support.

The takeaway: on managed platforms, the missing-file and emergency-repair steps are off the table. Restore is not just the safest option, it is usually the only option, which is one more reason to keep your backups safe and tested.

Bottom Line

A SQL Server Recovery Pending database is usually recoverable, and the data is usually fine. Work the safe order: read the error log, fix the root cause, bring the database online, and restore from backup before you ever run a repair. Save REPAIR_ALLOW_DATA_LOSS for the case where no backup exists and you accept the loss.

If a production database is down and the data matters, you do not have to work it alone. Red9’s SQL Server consulting team handles emergency recovery, and we have brought databases back that everyone else had written off.