RECOVERY_PENDING

RECOVERY_PENDING means SQL Server knows recovery is required but cannot start it, commonly because a database file is unavailable, the disk is full, permissions have changed, or the storage subsystem has failed. It does not automatically mean the database is corrupt.

USE master;

GO

SELECT

d.name,

d.state_desc,

d.user_access_desc,

d.recovery_model_desc,

d.log_reuse_wait_desc

FROM sys.databases AS d

WHERE d.name = N'myDatabase';

GO

USE master;

GO

SELECT

mf.file_id,

mf.type_desc,

mf.name AS logical_name,

mf.physical_name,

mf.state_desc,

mf.size * 8.0 / 1024 AS size_mb

FROM sys.master_files AS mf

WHERE mf.database_id = DB_ID(N'myDatabase');

GO

Disk Full / File or Drive Unavailable / Permissions

If the drive is full, add space or clear redundant files. If files/drives are missing, reconnect or restore. If permissions have changed, correct them. Then try:

ALTER DATABASE [myDatabase] SET ONLINE;

GO

LOG_BACKUP

Storage / IO

If the error log contains 823, 824, 825, bad block, CRC, delayed write, device not ready, or I/O requests taking longer than 15 seconds, treat this as a storage incident.

Before attempting database repair:

1. Preserve the SQL Server and Windows event logs.

2. Have the Windows/storage team investigate the full I/O path.

3. Correct the hardware, filesystem, SAN, driver, or firmware issue.

4. Prefer restoration from a known-good backup if the database is damaged.

Microsoft advises resolving the underlying hardware or I/O problem before restoring or repairing a database.

Corruption / Unrecoverable

If the error log indicates corruption or an unrecoverable log problem, the safest route is generally:

1. Preserve the damaged database files if storage permits.

2. Identify the last known-good full, differential, and log backups.

3. Restore to a new database name or alternate server first.

4. Run DBCC CHECKDB against the restored database.

5. Validate application data.

6. Switch over under your normal recovery procedure.

Emergency Mode

Only consider the following if:

• There is no usable backup

• Storage problems have been resolved

• You accept potential data loss

• You have first copied the MDF/NDF/LDF files where possible

• The business owner understands the risk

Avoid adding REPAIR_ALLOW_DATA_LOSS unless there is genuinely no restore route. It can deallocate damaged pages, remove records, and leave application-level inconsistencies

Stop before using the standalone recovery procedure. An AG database in RECOVERY_PENDING may need to be removed from the AG, restored/reseeded, and added back. A database that remains part of an Availability Group can have restrictions around restore and recovery operations.

Bibliography