Skip to content
Microsoft SQL Server

SQL Server Error 9001

The log for database is not available

Applies to: All supported SQL Server versions (2016 to 2025), Azure SQL Managed Instance
Last technically reviewed 24 October 2026 on SQL Server 2025 (17.0.1145.4)
The full message
The log for database 'AppDb' is not available. Check the operating system error log for related error messages. Resolve any errors and restart the database.
Other forms of this message
Error log form, as documented by Microsoft
Error: 9001, Severity: 21, State: 5.
The log for database 'ContosoDb' is not available. Check the operating system error log for related error messages. Resolve any errors and restart the database.
Older wording, as documented by Microsoft
The log for database 'ContosoDb' is not available. Check the event log for related error messages. Resolve any errors and restart the database.
Often logged next (error 3422, as documented by Microsoft)
Database ContosoDb was shutdown due to error 9001 in routine 'XdesRMFull::CommitInternal'. Restart for non-snapshot databases will be attempted after all connections to the database are aborted.
Error number
9001
Severity
21 (fatal: the connection ends; may indicate a serious problem)
State
Varies: 3, 4, 5 and 16 appear in Microsoft's examples; their meanings are not documented
Product
Microsoft SQL Server Database Engine
Versions
All supported SQL Server versions (2016 to 2025), Azure SQL Managed Instance
Last reviewed
24 October 2026

What it means

Error 9001 means SQL Server lost the ability to write to or read from a database's transaction log, so no transaction can continue in that database until the underlying problem is fixed and the database restarts.

Every change in a database must be written to its transaction log first. When the log becomes unusable, because its disk failed, the file is damaged, a TDE key cannot be reached or the log filled during a rollback, SQL Server takes the log offline and raises 9001 at severity 21. Severity 20 and above ends the current connection, so applications see their sessions dropped. SQL Server then shuts the database down and tries to restart it once all connections are gone (error 3422); for tempdb or a system database it may have to restart the whole service (error 3449).

9001 is the end result, not the cause. Microsoft's guidance is to resolve the errors logged before it first. Look in the SQL Server error log for 9002 (log full), 823 or 17053 (operating system I/O errors), 17204 (file could not be opened), 3313 or 3314 (redo or undo failed) or a decryption error, and in the Windows System event log for disk or controller warnings.

Common causes

  • The storage holding the log file failed or became unavailable (Microsoft's examples show OS error 21, "The device is not ready", and 1117, an I/O device error).
  • The log file is physically damaged, so SQL Server cannot read or write it.
  • Transparent Data Encryption could not decrypt or encrypt the log: the key vault or EKM provider was unreachable or failed.
  • The log filled up (9002) during a large transaction or rollback, for example on a full disk or a log with a size limit.

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.

Read what was logged before 9001

EXEC sp_readerrorlog 0, 1, N'9001';
EXEC sp_readerrorlog 0, 1, N'operating system error';
EXEC sp_readerrorlog 0, 1, N'AppDb';
What to look for

The 9001 lines and the errors just before them: 9002, 823, 17053, 17204, 3314 or a decryption error. That earlier error tells you which fix applies.

Is the database back online?

SELECT name, state_desc, user_access_desc, log_reuse_wait_desc
FROM sys.databases
WHERE name = N'AppDb';
What to look for

ONLINE means the automatic restart worked; check consistency next. RECOVERY_PENDING or SUSPECT means it did not, and the underlying cause is still there.

Where is the log, and how much space does its volume have?

SELECT mf.name AS logical_name, mf.physical_name, mf.size * 8 / 1024 AS size_mb,
       vs.volume_mount_point, vs.available_bytes / 1048576 AS free_mb
FROM sys.master_files AS mf
CROSS APPLY sys.dm_os_volume_stats(mf.database_id, mf.file_id) AS vs
WHERE mf.database_id = DB_ID(N'AppDb') AND mf.type_desc = N'LOG';
What to look for

The log file path and the free space on its volume. Check the same volume in the Windows System event log for device errors. (This query needs the database to be accessible.)

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 cause reported before 9001

Client or network side

For storage errors, bring the volume back and work with the hardware vendor on the I/O path (drivers, firmware, multipath). For TDE failures, restore access to the key vault or EKM provider. For a full log, free or add log space as described for error 9002. Nothing else helps until this is done.

Restart the database, then check its consistency

Changes database state

If SQL Server did not restart the database automatically, take it offline and online again (or restart the instance, as Microsoft suggests) so recovery runs. Once it is online, run DBCC CHECKDB to check for damage.

Caution: Do this only after the underlying cause is fixed. Taking the database offline disconnects every user; on storage that is still failing, recovery can fail again and leave the database SUSPECT.

ALTER DATABASE AppDb SET OFFLINE WITH ROLLBACK IMMEDIATE;
ALTER DATABASE AppDb SET ONLINE;
DBCC CHECKDB (N'AppDb') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Restore from backup if the log or data is damaged

Changes database state

If the database cannot come online or CHECKDB reports damage, restore the last known good full backup and the log backups after it.

Caution: RESTORE with REPLACE overwrites the database. Keep copies of the damaged files and error logs, and restore onto storage you have checked.

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 RECOVERY;

Examples

The error log when a log volume fails

Shown as documented by Microsoft; not reproduced here because it needs a log file that becomes unavailable. The sequence shows the operating system error first and 9001 as its result.

-- No statement: logged while the database is in use
EXEC sp_readerrorlog 0, 1, N'9001';
Result
Error: 823, Severity: 24, State: 2.
The operating system returned error 21(The device is not ready.) to SQL Server during a read at offset 0x000009afde6000 in file 'G:\Data\Files\ContosoDb_4.ldf'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
Error: 9001, Severity: 21, State: 3.
The log for database 'ContosoDb' is not available. Check the event log for related error messages. Resolve any errors and restart the database.

How to prevent it

Put transaction logs on reliable, monitored storage, keep drivers and firmware current, and alert on 823, 17053, 9002 and 9001 in the error log so the first sign of trouble is noticed.

Size logs with headroom and keep log backups running so a long transaction cannot fill the log during rollback. With TDE and an external key store, monitor access to the key vault or EKM provider.

Common questions

Why were all connections to the database dropped?

Severity 21 is a fatal error for the database: SQL Server ends the sessions using it and shuts it down so it can try to restart and recover it.

Does 9001 mean data is lost?

Not necessarily. If the cause was temporary and the database restarts and recovers, committed work is kept. If the log file is damaged, you may need to restore from backup.

Is 9001 the same as a full log?

No. A full log is error 9002 and the database stays online. 9001 means the log is unusable; a full log during a rollback is one of several ways to get there.

Learn more on CodeWithSQL

Official documentation

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.

Still stuck on a SQL Server error?

Browse the full SQL Server error library, or get hands-on help from an experienced SQL professional.