How to fix SQL Server error 9001 (the log for the database is not available)
This means SQL Server lost access to the database transaction log, so it took the log offline to protect the database. It is almost always a storage problem. The quick fix is to restore access to the disk, then take the database offline and online again. Jump to your situation below or work through the methods in order.
By Neeraj Singh ~8 min Updated Jun 2026 93% found this helpful
Error message
Error: 9001, Severity: 21, State: 1. The log for database 'YourDB' is not available. Check the event log for related error messages. Resolve any errors and restart the database.
Summary
Error 9001 means SQL Server lost contact with a database transaction log file and took the log offline to avoid corrupting the database. It is almost always a storage issue rather than corruption: a SAN or disk dropped out, the LDF was deleted, moved or renamed, the volume was not online yet when SQL Server started, antivirus locked the file, or AUTO_CLOSE kept opening and closing the database. The quickest reliable fix is to restore access to the storage, then take the database OFFLINE and back ONLINE to re-establish the file handle, or simply restart the SQL Server service. Check the Windows event log first, because the 9001 line itself tells you to resolve the underlying error there. Restore from backup only if the log file is genuinely gone or corrupt.
What this error means
Error 9001 (Severity 21) is raised when SQL Server can no longer reach a database transaction log. To protect the database from a half-written state, the engine takes the log offline and shuts the database down, often logging a companion message such as “Database was shutdown due to error 9001”. You may also see “Operating system error 2 (The system cannot find the file specified)” in the log.
Because SQL Server only loses a log it could previously see, the cause is nearly always external: the storage hosting the LDF went away, the file was removed, or something locked or hid it. That is why the error message points you at the Windows event log, and why the fix is usually to restore access and re-open the file rather than to repair the database.
Common causes
The disk or SAN hosting the LDF dropped out or disconnected.
The LDF file was deleted, moved or renamed out from under SQL Server.
The storage volume was not online yet when the SQL Server service started.
Antivirus or on-access scanning locked the log file.
AUTO_CLOSE is on, so the database keeps opening and closing the file.
NTFS permissions on the Log folder changed, blocking the service account.
There was no free space for the log to expand on its volume.
Expert insight
“9001 reads like corruption but it almost never is, the log simply vanished from under SQL Server. The very first line of the error tells you to check the event log, and that is exactly where the truth is: a SAN that blinked, a drive that was not mounted at boot, an antivirus that grabbed the file. Once the storage is back, the cleanest trick is to take the database offline and straight back online, which forces SQL Server to re-open the log handle. A service restart does the same thing. I only reach for a restore when the LDF is genuinely gone, and then I go hunting for why the disk disappeared so it does not happen again.”
Manager, Tech Support & Operations · 19+ years fixing Windows and system errors
✓ How to fix it
Method 1
Check the Windows event log for the real cause
1The 9001 message tells you to look here, so start with the Windows System and Application event logs at the time of the error.
2Look for disk, SAN or controller errors, or messages like “Operating system error 2 (cannot find the file)”, which name the underlying problem.
3Resolve that error first, because 9001 is a symptom of it, not the root cause.
Method 2
Restore access to the storage
1Bring the disk, SAN or mount point hosting the LDF back online and confirm the volume is connected.
2Verify the log file is present and readable at its expected path, for example with dir or File Explorer under the service account.
3If the file was moved, put it back, or update the path so SQL Server can find it.
Method 3
Take the database offline then online
1Once the storage is back, force SQL Server to re-open the log handle by cycling the database:
ALTER DATABASE [YourDB] SET OFFLINE;
ALTER DATABASE [YourDB] SET ONLINE;
2This is the most common quick fix and re-establishes the connection to a log that is present but was lost.
3Restarting the SQL Server service has the same effect if a single database will not go offline.
Method 4
Turn AUTO_CLOSE off
1Repeated 9001 errors on activity often trace back to AUTO_CLOSE, which opens and closes the files constantly. Turn it off:
ALTER DATABASE [YourDB] SET AUTO_CLOSE OFF;
2Apply this to every user database that has it enabled, as it is rarely a good setting on a server.
3This removes the churn that intermittently loses the log handle.
Method 5
If storage mounts slowly at boot, delay SQL startup
1When 9001 appears only after a server restart, the volume was probably not ready when SQL Server started.
2Set the SQL Server service to Automatic (Delayed Start) so the storage has time to come online first.
3For clustered or SAN storage, work with your storage team to ensure the volume mounts before SQL Server.
Method 6
Exclude database files from antivirus
1Add the data and log file folders to your antivirus on-access scanning exclusions.
2On-access scanning can briefly lock the LDF, which SQL Server sees as the log becoming unavailable.
3Exclude the MDF, NDF and LDF extensions and the SQL backup folders.
Method 7
If the log is gone or corrupt, restore from backup
1If the LDF is genuinely missing or damaged, restore the database from a known-good backup, full then log chain.
2If you suspect corruption rather than a missing file, bring the database online in emergency mode and run CHECKDB to assess it:
ALTER DATABASE [YourDB] SET EMERGENCY;
DBCC CHECKDB ('YourDB');
3Where no backup exists, an emergency-mode rebuild of the log is a last resort that can lose data.
Method 8
Prevent it from happening again
1Keep database and log files off the boot volume and on stable, monitored storage.
2Monitor the storage path and free space, and keep antivirus exclusions in place.
3Leave AUTO_CLOSE off and set delayed start where storage mounts slowly.
9001 is a protective shutdown, not usually corruption, so the first instinct should be to restore storage access and re-open the log, not to repair or rebuild. Only treat the log as lost when the file is genuinely missing or the disk is confirmed dead. If you keep seeing 9001, the underlying storage is unreliable, so find and fix the disk, SAN or driver before it turns into real corruption.
Frequently asked questions
What does SQL Server error 9001 mean?
It means SQL Server lost access to a database transaction log file and took the log offline to protect the database. It is almost always a storage problem rather than corruption.
How do I fix error 9001 quickly?
After restoring access to the storage, take the database OFFLINE and then ONLINE, or restart the SQL Server service. That re-establishes the file handle to a log that is present but was lost.
Does error 9001 mean my database is corrupt?
Usually no. SQL Server takes the log offline because it disappeared, not because it is damaged. Check the Windows event log for a disk or SAN error, which is the real cause.
Why does 9001 happen after a server restart?
The storage volume was probably not mounted yet when SQL Server started. Set the SQL Server service to Automatic (Delayed Start) so the disk comes online first.
Can AUTO_CLOSE cause error 9001?
Yes. With AUTO_CLOSE on, the database constantly opens and closes its files, which can intermittently lose the log handle. Turn it off with ALTER DATABASE SET AUTO_CLOSE OFF.
Do I need to restore from backup to fix 9001?
Only if the log file is genuinely gone or corrupt. In most cases restoring storage access and cycling the database offline and online is enough.
Still not working?
If the database will not come back online after the storage is restored, or 9001 returns every few minutes, the disk or SAN underneath is unstable. Move the database to healthy storage and restore the most recent good backup, and have your storage team investigate the dropouts. You can also submit your error to us for a tailored fix.
