Fix error 9001: the log for database is not available

Production application went down with error 9001, the log for database is not available. The database shows suspect adjacent behaviour, some queries error while others worked moments ago.

What happened and what is the correct recovery order?

9001 means SQL Server lost the ability to write the transaction log mid flight, almost always because the IO path underneath dropped, a storage disconnect, controller hiccup, VM storage stall, a full or failing disk. The database took itself offline logically to protect consistency. The recovery order matters because the database is usually fine and the storage usually is not, so:

1

Read before touching: the SQL Server error log around the 9001 timestamp names the failing file path and carries the underlying OS error, and the Windows System event log at the same moment shows the disk or controller event that started it. This pair tells you whether the storage merely blinked or is dying, which decides everything after.

2

Fix the storage story first: reconnect the path, clear the full disk, resolve the VM storage stall. Restarting the database on top of broken storage just schedules the next 9001.

3

Cycle the database, not the service: ALTER DATABASE yours SET OFFLINE WITH ROLLBACK IMMEDIATE, then SET ONLINE. Coming online runs crash recovery against the log and the database returns consistent, the same mechanism a service restart would use without taking every other database down with it.

4

Verify before celebrating: DBCC CHECKDB on the recovered database. Clean output plus a benign storage explanation closes the incident. Errors in CHECKDB output move this from a 9001 thread to a corruption response, restore from backups being the honest path, and either way the log backup chain deserves a fresh full backup tonight given the excitement.

If the errorlog and event log show this was not the first blink, treat the storage as the patient rather than the database: intermittent IO drops recur on their own schedule and the next one may not land as gently. The database layer did its job here, 9001 taking the database offline is protection working, the layer below is where the trust was lost.

Event log showed the SAN path failover exactly at the timestamp, storage team confirmed and stabilized it. Offline online cycle brought it back in two minutes, CHECKDB clean, backup taken. The order mattered, my instinct was to restart the service first which would have hidden the evidence.