SQL Server Error 3414

Error number

3414

Severity

21 (fatal: the connection ends; may indicate a serious problem)

State

1 (from the error log example in Microsoft's reference; not reproduced here)

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

24 October 2026

What it means

Error 3414 is written to the SQL Server error log when recovery of a database fails; the database is marked SUSPECT and stays unusable until the cause is fixed or the database is restored.

Each time a database starts (service startup, attach, SET ONLINE, end of a restore) recovery replays committed work from the log and rolls back unfinished transactions. If that hits an error it cannot work around, SQL Server writes 3414 to the error log and marks the database SUSPECT. Applications never see 3414 itself; they get error 926 when they try to use the database. Microsoft notes that when this happens to tempdb, the instance shuts down.

3414 only reports that recovery gave up. The cause is the error logged just before it by the same session (the same spid value on each line), for example an 824 checksum failure on a log block, or an 823 operating system I/O error. The catalogue in sys.messages lists severity 10, but Microsoft's documented error log entry shows severity 21; the level was not observed here.

Common causes

• A damaged page or log block read during recovery, typically reported first as error 824 (bad checksum) or 823 (operating system I/O error).
• A transient storage problem at startup: a volume, SAN path or network share that was briefly unavailable while recovery ran.
• A transaction log file that was replaced, truncated or copied from a different point in time.
• Other recovery failures logged just before it, such as errors 3313 or 3314 during redo or undo.

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.

EXEC sp_readerrorlog 0, 1, N'during recovery';
EXEC sp_readerrorlog 0, 1, N'AppDb';
EXEC sp_readerrorlog 1, 1, N'AppDb';   -- the previous log, if the service restarted

SELECT name, state_desc, user_access_desc, recovery_model_desc
FROM sys.databases
WHERE state_desc IN ('SUSPECT', 'RECOVERY_PENDING', 'EMERGENCY');

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;

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;

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.

ALTER DATABASE AppDb SET OFFLINE;
ALTER DATABASE AppDb SET ONLINE;

BACKUP LOG AppDb TO DISK = N'D:\Backups\AppDb_tail.trn' WITH NO_TRUNCATE;
RESTORE DATABASE AppDb FROM DISK = N'D:\Backups\AppDb_full.bak' WITH NORECOVERY, REPLACE;
RESTORE LOG AppDb FROM DISK = N'D:\Backups\AppDb_tail.trn' WITH RECOVERY;

Examples

The error log entry when recovery fails

Shown as documented by Microsoft; not reproduced here because it needs a database whose recovery fails. The engine wording from sys.messages is shown, with placeholder database ID values; the error appears in the SQL Server error log during startup, not in a query window.

-- No statement: logged when the database starts, for example at service startup
EXEC sp_readerrorlog 0, 1, N'during recovery';

An error occurred during recovery, preventing the database 'AppDb' (5:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

How to prevent it

Take full and log backups WITH CHECKSUM and test restores regularly, so a failed recovery is an inconvenience rather than a disaster. Keep PAGE_VERIFY CHECKSUM on so damage is found when pages are read, not during a later recovery.

Alert on errors 823, 824 and 825 and on databases that are not ONLINE, and keep storage drivers and firmware current with write caches protected against power loss.

Common questions

Learn more on CodeWithSQL

• Working with large databases

Official documentation

• MSSQLSERVER_3414 (Microsoft Learn)
• Deferred transactions
• Database states
• Tail-log backups

Last technically reviewed 24 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.