- Error number
- 926
- Severity
- 14 (user-correctable error)
- State
- Not documented by Microsoft
- Product
- Microsoft SQL Server Database Engine
- Versions
- All supported SQL Server versions (2016 to 2025), Azure SQL Managed Instance
- Category
- Database State & Recovery
- Last reviewed
- 23 October 2026
On this page
What it means
Error 926 means SQL Server started recovering the database, could not finish, and marked it SUSPECT, so nobody can use it until the cause is fixed and the database is restored or recovered.
Every time a database starts (at service startup, after an attach or at the end of a RESTORE), recovery replays and rolls back work from the transaction log so the data is consistent. If recovery hits an error it cannot get past, typically a damaged page or log record, or an I/O error, SQL Server stops it and marks the database SUSPECT. Every later attempt to use the database returns 926 at severity 14.
The 926 itself does not say what went wrong. The reason is in the SQL Server error log, in the messages written when recovery failed (for example 823, 824, 9004 or 3414). If the service has restarted since, look in the previous error logs. Treat SUSPECT as possible data damage: gather evidence first and change nothing until you know the cause.
Common causes
- A damaged data or log page met during recovery, usually caused by storage, a driver or a power loss without a safe write cache (often logged as error 823 or 824).
- A damaged or incomplete transaction log, for example after a log file was replaced, deleted or restored from a different point in time.
- An I/O failure while recovery was running: a disk, SAN path or network share that dropped out.
- A failure during RESTORE or attach of a database whose files or backup were already damaged.
Diagnose it
Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.
Which databases are SUSPECT?
SELECT name, state_desc, user_access_desc, recovery_model_desc
FROM sys.databases
WHERE state_desc IN ('SUSPECT', 'RECOVERY_PENDING', 'EMERGENCY');The affected database shows SUSPECT. RECOVERY_PENDING is a different problem (recovery could not even start, see error 945).
Read why recovery failed
EXEC sp_readerrorlog 0, 1, N'AppDb';
EXEC sp_readerrorlog 1, 1, N'AppDb'; -- the previous log, if the service restartedThe messages just before the database was marked suspect: the error number, the file and page, and whether it happened during redo or undo. This decides everything that follows.
Are damaged pages recorded?
SELECT DB_NAME(database_id) AS database_name, file_id, page_id,
event_type, error_count, last_update_date
FROM msdb.dbo.suspect_pages
ORDER BY last_update_date DESC;Rows for the affected database point to damaged pages and storage problems. Rows in other databases on the same volume mean the storage is still failing.
Which backups can you restore from?
SELECT TOP (20) bs.type, bs.backup_start_date, bs.backup_finish_date,
bs.has_backup_checksums, mf.physical_device_name
FROM msdb.dbo.backupset AS bs
JOIN msdb.dbo.backupmediafamily AS mf ON mf.media_set_id = bs.media_set_id
WHERE bs.database_name = N'AppDb'
ORDER BY bs.backup_finish_date DESC;The latest full backup (type D), differentials (I) and the log backups (L) after it. An unbroken chain of log backups lets you restore with little or no data loss.
How to fix it
Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.
Fix the underlying storage or file problem first
Client or network sideIf the error log shows I/O errors (823, 824), check the Windows System event log, storage firmware and drivers, and filter drivers such as antivirus. Restoring onto storage that is still failing only produces new damage. Keep copies of the error logs and, if possible, of the database files as they are now.
Restore from backup
Changes database stateThis is the supported recovery for a suspect database. Back up the tail of the log first if the log file is readable, then restore the last full backup, any differential and every log backup in order, and run DBCC CHECKDB on the result. Restoring under a new name first lets you check the copy before replacing anything.
Caution: RESTORE with REPLACE overwrites the suspect database and the evidence in it. Take the tail-log backup and keep copies of the original files before you replace it.
-- 1. Tail of the log (works on a damaged database if the log is readable)
BACKUP LOG AppDb TO DISK = N'D:\Backups\AppDb_tail.trn' WITH NO_TRUNCATE;
-- 2. Restore the chain
RESTORE DATABASE AppDb FROM DISK = N'D:\Backups\AppDb_full.bak' WITH NORECOVERY, REPLACE;
RESTORE LOG AppDb FROM DISK = N'D:\Backups\AppDb_log_1.trn' WITH NORECOVERY;
RESTORE LOG AppDb FROM DISK = N'D:\Backups\AppDb_tail.trn' WITH RECOVERY;Expert last resort when no backup exists: EMERGENCY mode
Changes database stateOnly when there is no usable backup, and preferably with Microsoft support or an experienced DBA, EMERGENCY mode lets a sysadmin read the database as it is, so you can run DBCC CHECKDB (without a repair option) to measure the damage and copy out whatever data is still readable into a new database. Do not reach for DBCC CHECKDB repair options here as a routine fix: repair with data loss deletes whatever it cannot fix, breaks transactional consistency and relationships between tables, and is the very last step after copying the data out, on a copy of the files.
Caution: EMERGENCY mode exposes a database that may be inconsistent. Work on a copy of the files where possible, never let applications reconnect to it, and treat anything read from it as unverified. This is not a substitute for restoring a backup.
ALTER DATABASE AppDb SET EMERGENCY;
DBCC CHECKDB (N'AppDb') WITH NO_INFOMSGS, ALL_ERRORMSGS; -- report onlyExamples
Opening a database that failed recovery
Shown as documented by Microsoft; not reproduced here because it needs a database whose recovery fails. The state is not documented, so no header is shown. Every connection or query that uses the database gets the same message until the database is restored or recovered.
USE AppDb;Database 'AppDb' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information.
How to prevent it
Take regular full and log backups WITH CHECKSUM, restore them on a schedule to prove they work, and keep PAGE_VERIFY CHECKSUM on so damage is detected when pages are read rather than during a later recovery.
Run DBCC CHECKDB regularly, alert on errors 823, 824 and 825 and on databases that are not ONLINE, and make sure storage write caches are battery or flash backed so a power loss cannot leave half-written pages.
Common questions
Can I just reset the SUSPECT status?
Resetting the flag does not repair anything; recovery failed for a reason. If the cause was temporary (a disk that was briefly unavailable) and is now fixed, taking the database OFFLINE and back ONLINE retries recovery. If the log or data is damaged, restore from backup.
Should I detach the suspect database and attach it again?
No. A database that cannot recover may not attach again, which leaves you with fewer options. Keep it attached, keep copies of its files, and restore from backup.
How much data will I lose?
With the FULL recovery model, an unbroken chain of log backups and a successful tail-log backup, usually none. Without log backups, you lose everything since the last full or differential backup.
Learn more on CodeWithSQL
Official documentation
Last technically reviewed 23 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.