How to fix SQL Server error 9004 (an error occurred while processing the log)
This means the transaction log for a database is damaged, so SQL Server cannot process it during recovery or restore. The safe fix is to restore from a known-good backup. If you have no backup, you rebuild the log in emergency mode, which can lose data. Jump to your situation below or work through the methods in order.
By Neeraj Singh ~10 min Updated Jun 2026 94% found this helpful
Error message
Error: 9004, Severity: 21, State: 1. An error occurred while processing the log for database 'YourDB'. If possible, restore from backup. If a backup is not available, it might be necessary to rebuild the log.
Summary
Error 9004 means the contents of a database transaction log are damaged, so SQL Server cannot process the log during startup recovery, an ALTER DATABASE, or a restore. It is usually caused by hardware, disk or I/O problems, an unclean shutdown, or a bad block in the LDF file, and it often appears in the ERRORLOG next to error 3414. Because DBCC CHECKDB does not check the transaction log, the reliable fix is to restore the database from a known-good backup. If no backup exists, you can force the database online in emergency mode and rebuild the log, but this can lose any transactions that were still in the log. Always fix the underlying disk problem so it does not happen again.
What this error means
Error 9004 (usually Severity 21) means SQL Server tried to read the transaction log for a database and found it inconsistent. The log is checked block by block for parity, sector and logical consistency, and a failure on any of those raises 9004. Because severity 21 is a fatal error, the session is disconnected and the database is usually left in Recovery Pending or Suspect.
It most often appears in the ERRORLOG or the Windows Application event log during automatic recovery when the service starts, frequently alongside error 3414. The cause is almost always a hardware, disk or I/O fault that damaged the LDF file, or an unclean shutdown. One important detail: DBCC CHECKDB does not inspect the transaction log, so it cannot detect or repair 9004. The dependable cure is a restore from backup.
Common causes
A hardware, disk or storage controller fault damaged the LDF file, often with 823 or 824 I/O errors.
The server or SQL Server service shut down uncleanly, leaving the log inconsistent.
A bad block, torn page or parity failure inside a virtual log file (VLF).
The log file header is corrupt, which can also raise Msg 5172.
The LDF was moved, replaced or does not match the data file during an attach.
A backup whose log portion is damaged raises 9004 during the restore itself.
A known bug on standby restores or large TDE compressed backups on older builds.
Expert insight
“9004 looks terrifying because the log is damaged and severity 21 disconnects you, but the playbook is calm and simple. First I never reach for DBCC CHECKDB, it does not even read the transaction log, so it cannot fix this. I go straight to the last known-good backup and restore, which is clean and loses nothing. Only when there is genuinely no backup do I force the database online in emergency mode and rebuild the log, and even then I tell the owner up front that some in-flight transactions are gone. Then I find the failing disk, because 9004 is almost always hardware shouting at you.”
Manager, Tech Support & Operations · 19+ years fixing Windows and system errors
✓ How to fix it
Method 1
Read the error log and confirm the database and state
1Open the SQL Server ERRORLOG (its folder is the -e startup parameter, usually ...\MSSQL\Log\ERRORLOG) or the Windows Application event log, find the 9004 line and note the database name and State.
2Look for a nearby Error 3414 (recovery failed) and any 823 or 824 I/O errors, which point at a failing disk.
3Once SQL is reachable, read the log from a query window with:
EXEC sys.xp_readerrorlog 0;
Method 2
Restore from a known-good backup (preferred)
1This is the safe fix that loses nothing up to the last backup. If the log is still readable, take a tail-log backup first, then restore the last good full backup followed by the log chain.
2From a query window, restoring full then log:
RESTORE DATABASE [YourDB] FROM DISK = 'D:\Backup\YourDB_full.bak' WITH REPLACE, NORECOVERY;
RESTORE LOG [YourDB] FROM DISK = 'D:\Backup\YourDB_log.trn' WITH RECOVERY;
3Bring the database online and verify it is accessible. If 9004 happens on the restore itself, that backup’s log is damaged, so use an earlier backup.
Method 3
Force the database online in emergency mode
1If there is no usable backup, recover what you can before rebuilding. Put the database into emergency mode and single user:
ALTER DATABASE [YourDB] SET EMERGENCY;
ALTER DATABASE [YourDB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
2In emergency mode SQL can often still read the data pages, so script out or copy the critical tables to another database right away as a safety net.
3Keep the database in single user while you run the rebuild in Method 4.
Method 4
Rebuild the transaction log (last resort, data loss)
1Rebuilding the log discards any transactions still held in it, so only do this with no backup and after copying out what you can. In emergency mode, run the repair:
DBCC CHECKDB ([YourDB], REPAIR_ALLOW_DATA_LOSS);
2In emergency mode this forces the database online and rebuilds the damaged log. When it finishes, return the database to multi user:
ALTER DATABASE [YourDB] SET MULTI_USER;
3Run DBCC CHECKDB ([YourDB]) again with no repair option to confirm the database is now consistent.
Method 5
Rebuild the log during an attach (ATTACH_REBUILD_LOG)
1If 9004 appears when attaching a database whose LDF is missing or mismatched and the database was shut down cleanly, you can rebuild the log on attach.
2Run, listing only the data file:
CREATE DATABASE [YourDB] ON (FILENAME = 'D:\Data\YourDB.mdf') FOR ATTACH_REBUILD_LOG;
3This creates a fresh log. If the database was not shut down cleanly it will not attach, so restore from backup instead.
Method 6
Fix the underlying disk or I/O fault
19004 is usually hardware shouting. Check the Windows System and Application event logs for disk, controller or 823/824 errors around the time of the failure.
2Run chkdsk on the volume holding the LDF, review the drive SMART health, and update the storage controller firmware and driver.
3Move the database to healthy storage before putting it back into production.
Method 7
Patch a known restore or standby bug
1If 9004 appears only on a log-shipping or standby restore, or when restoring a large TDE compressed backup, you may be hitting a fixed bug rather than real corruption.
2Apply the latest cumulative update and service pack for your SQL Server version.
3For the standby restore on advanced-format (4K sector) disks, enable trace flag 3057 after patching, per the Microsoft KB.
Method 8
Verify recovery and protect against a repeat
1After the database is online, run a full DBCC CHECKDB and take a fresh full backup straight away.
2Confirm the recovery model, and that the log autogrowth and the disk have healthy free space.
3Set up regular full and log backups and disk monitoring so the next 9004 is a quick restore, not a rebuild.
DBCC CHECKDB does not check the transaction log, so it cannot find or fix error 9004 on its own. The only clean recovery is a restore from a known-good backup. Rebuilding the log with REPAIR_ALLOW_DATA_LOSS in emergency mode is a last resort that can lose data, so copy out anything critical first and keep tested backups so you never have to use it.
Frequently asked questions
What does SQL Server error 9004 mean?
It means the transaction log for a database is damaged, so SQL Server cannot process it during recovery, an ALTER DATABASE or a restore. It is a severity 21 error and usually leaves the database in Recovery Pending or Suspect.
Can DBCC CHECKDB fix error 9004?
No. CHECKDB does not inspect the transaction log, so it cannot detect or repair 9004 on its own. The clean fix is to restore from a known-good backup. In emergency mode, REPAIR_ALLOW_DATA_LOSS can rebuild the log, but that can lose data.
Will I lose data fixing error 9004?
Not if you restore from a good backup, which loses nothing up to the last backup. You only risk data loss if you have no backup and rebuild the log in emergency mode, which discards transactions still held in the log.
Why does 9004 often appear with error 3414?
3414 means recovery failed for the database. 9004 is the reason: the log was damaged while recovery tried to process it. You usually see both together in the ERRORLOG at startup.
What causes the transaction log to get damaged?
Almost always a hardware, disk or I/O fault, or an unclean shutdown that left a bad block or torn page in the LDF. Check the Windows event log for disk and 823 or 824 I/O errors.
It only happens when I restore a backup, why?
The log portion of that backup is damaged, or you are hitting a known bug on standby restores or large TDE compressed backups. Use an earlier backup, and apply the latest cumulative update for your SQL Server version.
Still not working?
If the restore fails too and emergency-mode repair will not bring the database online, the corruption may be too deep or the disk may still be failing. Move to healthy storage, restore the most recent backup that does pass, and on a production system engage your DBA or Microsoft support before forcing repairs. You can also submit your error to us for a tailored fix.
