Het .ldf-bestand is handmatig verwijderd of verplaatst terwijl SQL Server niet draaide — bij de volgende start kan de engine het log niet vinden en plaatst de database in RECOVERY_PENDING of SUSPECT state.. De schijf of het volume waarop de logfile staat is uitgevallen, losgekoppeld of vol geraakt (geen vrije ruimte meer). SQL Server kan dan geen nieuwe log-records schrijven en sluit de database af om corruptie te voorkomen.. De database is geattacht via een ATTACH_REBUILD_LOG of zonder .ldf-pad, en SQL Server kon geen nieuw logbestand aanmaken — dit gebeurt vaak na het kopiëren van alleen het .mdf-bestand naar een andere server.. Een storage-snapshot of SAN-operatie heeft de logfile tijdelijk offline geplaatst of in een inconsistente staat achtergelaten, waarna SQL Server de database in emergency mode zet.. Anti-virussoftware of een backup-agent heeft het .ldf-bestand vergrendeld of in quarantaine geplaatst. SQL Server verliest dan schrijftoegang, wat leidt tot error 9001 in het SQL Server errorlog.. De database was al in een slechte state door een eerdere crash (bijv. stroom uitgevallen tijdens een checkpoint), en bij herstart slaagde de automatische recovery niet omdat het log incompleet of onleesbaar is.. TempDB of een systeemschijf is vol geraakt, waardoor SQL Server intern geen ruimte meer heeft voor log-operaties — dit kan indirect ook user databases raken als internal log space tijdelijk gedeeld wordt.

Stap 1 — Check de database state en de locatie van het logbestand: SELECT name, state_desc, log_reuse_wait_desc FROM sys.databases WHERE name = 'yourdb'; SELECT name, physical_name, state_desc FROM sys.master_files WHERE database_id = DB_ID('yourdb'); Als state_desc SUSPECT, RECOVERY_PENDING of OFFLINE is, bevestigt dat de error actief is. Noteer het pad van het .ldf-bestand.. Stap 2 — Controleer of het logbestand fysiek aanwezig is op de gerapporteerde locatie (bijv. via xp_cmdshell als die aan staat, of buiten SQL Server via de OS-shell): EXEC xp_cmdshell 'dir C:\SQLData\yourdb_log.ldf'; Als het bestand ontbreekt, ga naar stap 3. Als het aanwezig is maar SQL Server het niet kan lezen, controleer schijfgezondheid en NTFS-rechten voor het SQL Server service-account.. Stap 3 — Controleer de Windows Event Viewer (System en Application log) en het SQL Server errorlog op storage-fouten: EXEC xp_readerrorlog 0, 1, N'9001'; EXEC xp_readerrorlog 0, 1, N'17207'; Disk I/O errors (17207, 823, 824) naast 9001 wijzen op een hardware- of storage-probleem. Los dit eerst op voordat je de database repareert.. Stap 4 — Als er een recente backup beschikbaar is, herstel direct: RESTORE DATABASE [yourdb] FROM DISK = 'D:\Backups\yourdb_full.bak' WITH NORECOVERY; RESTORE LOG [yourdb] FROM DISK = 'D:\Backups\yourdb_log.bak' WITH RECOVERY; Dit is de enige optie zonder dataverlies. Controleer daarna de database state opnieuw.. Stap 5 — Als er geen bruikbare backup is en het logbestand echt weg is, probeer emergency-mode repair (LET OP: mogelijke dataverlies): ALTER DATABASE [yourdb] SET EMERGENCY; ALTER DATABASE [yourdb] SET SINGLE_USER WITH ROLLBACK IMMEDIATE; DBCC CHECKDB ([yourdb], REPAIR_ALLOW_DATA_LOSS); ALTER DATABASE [yourdb] SET MULTI_USER; ALTER DATABASE [yourdb] SET ONLINE; Controleer daarna op dataverlies via DBCC CHECKDB zonder repair-optie.. Stap 6 — Na herstel: verifieer dat alle ADF linked services en Power BI datasets opnieuw verbinding kunnen maken. Test een eenvoudige query via de connector: SELECT TOP 1 1 FROM sys.tables; Start vervolgens de gefaalde ADF-pipeline handmatig opnieuw via Azure Portal → Data Factory → Monitor → Rerun.. Stap 7 — Preventie: verplaats logbestanden naar een volume met voldoende ruimte en redundantie. Stel een SQL Server Agent alert in op error 9001: EXEC msdb.dbo.sp_add_alert @name = N'Error 9001 - Log not available', @message_id = 9001, @severity = 0, @enabled = 1, @job_name = N'Notify DBA'; Voeg ook een disk-space monitor toe zodat je ruimteproblemen vóór bent.

Critical severityconfiguration

SQL Server Error:
9001

What does this error mean?

SQL Server error 9001 betekent dat de engine de transactielogfile van de database niet meer kan bereiken. Dit kan komen doordat het .ldf-bestand fysiek is verdwenen, de schijf waarop het staat niet meer beschikbaar is, of de database in een inconsistente state terecht is gekomen na een onverwachte afsluiting. Zodra dit gebeurt zet SQL Server de database offline — alle verbindingen worden verbroken. In een data-pipeline-context betekent dit dat elke ADF-activiteit die tegen die database leest of schrijft onmiddellijk faalt met een connectie- of uitvoerfout. De database is niet readonly; hij is volledig onbereikbaar tot het log-probleem is opgelost.

Common causes

1Het .ldf-bestand is handmatig verwijderd of verplaatst terwijl SQL Server niet draaide — bij de volgende start kan de engine het log niet vinden en plaatst de database in RECOVERY_PENDING of SUSPECT state.
2De schijf of het volume waarop de logfile staat is uitgevallen, losgekoppeld of vol geraakt (geen vrije ruimte meer). SQL Server kan dan geen nieuwe log-records schrijven en sluit de database af om corruptie te voorkomen.
3De database is geattacht via een ATTACH_REBUILD_LOG of zonder .ldf-pad, en SQL Server kon geen nieuw logbestand aanmaken — dit gebeurt vaak na het kopiëren van alleen het .mdf-bestand naar een andere server.
4Een storage-snapshot of SAN-operatie heeft de logfile tijdelijk offline geplaatst of in een inconsistente staat achtergelaten, waarna SQL Server de database in emergency mode zet.
5Anti-virussoftware of een backup-agent heeft het .ldf-bestand vergrendeld of in quarantaine geplaatst. SQL Server verliest dan schrijftoegang, wat leidt tot error 9001 in het SQL Server errorlog.
6De database was al in een slechte state door een eerdere crash (bijv. stroom uitgevallen tijdens een checkpoint), en bij herstart slaagde de automatische recovery niet omdat het log incompleet of onleesbaar is.
7TempDB of een systeemschijf is vol geraakt, waardoor SQL Server intern geen ruimte meer heeft voor log-operaties — dit kan indirect ook user databases raken als internal log space tijdelijk gedeeld wordt.

How to fix it

1Stap 1 — Check de database state en de locatie van het logbestand: SELECT name, state_desc, log_reuse_wait_desc FROM sys.databases WHERE name = 'yourdb'; SELECT name, physical_name, state_desc FROM sys.master_files WHERE database_id = DB_ID('yourdb'); Als state_desc SUSPECT, RECOVERY_PENDING of OFFLINE is, bevestigt dat de error actief is. Noteer het pad van het .ldf-bestand.
2Stap 2 — Controleer of het logbestand fysiek aanwezig is op de gerapporteerde locatie (bijv. via xp_cmdshell als die aan staat, of buiten SQL Server via de OS-shell): EXEC xp_cmdshell 'dir C:\SQLData\yourdb_log.ldf'; Als het bestand ontbreekt, ga naar stap 3. Als het aanwezig is maar SQL Server het niet kan lezen, controleer schijfgezondheid en NTFS-rechten voor het SQL Server service-account.
3Stap 3 — Controleer de Windows Event Viewer (System en Application log) en het SQL Server errorlog op storage-fouten: EXEC xp_readerrorlog 0, 1, N'9001'; EXEC xp_readerrorlog 0, 1, N'17207'; Disk I/O errors (17207, 823, 824) naast 9001 wijzen op een hardware- of storage-probleem. Los dit eerst op voordat je de database repareert.
4Stap 4 — Als er een recente backup beschikbaar is, herstel direct: RESTORE DATABASE [yourdb] FROM DISK = 'D:\Backups\yourdb_full.bak' WITH NORECOVERY; RESTORE LOG [yourdb] FROM DISK = 'D:\Backups\yourdb_log.bak' WITH RECOVERY; Dit is de enige optie zonder dataverlies. Controleer daarna de database state opnieuw.
5Stap 5 — Als er geen bruikbare backup is en het logbestand echt weg is, probeer emergency-mode repair (LET OP: mogelijke dataverlies): ALTER DATABASE [yourdb] SET EMERGENCY; ALTER DATABASE [yourdb] SET SINGLE_USER WITH ROLLBACK IMMEDIATE; DBCC CHECKDB ([yourdb], REPAIR_ALLOW_DATA_LOSS); ALTER DATABASE [yourdb] SET MULTI_USER; ALTER DATABASE [yourdb] SET ONLINE; Controleer daarna op dataverlies via DBCC CHECKDB zonder repair-optie.
6Stap 6 — Na herstel: verifieer dat alle ADF linked services en Power BI datasets opnieuw verbinding kunnen maken. Test een eenvoudige query via de connector: SELECT TOP 1 1 FROM sys.tables; Start vervolgens de gefaalde ADF-pipeline handmatig opnieuw via Azure Portal → Data Factory → Monitor → Rerun.
7Stap 7 — Preventie: verplaats logbestanden naar een volume met voldoende ruimte en redundantie. Stel een SQL Server Agent alert in op error 9001: EXEC msdb.dbo.sp_add_alert @name = N'Error 9001 - Log not available', @message_id = 9001, @severity = 0, @enabled = 1, @job_name = N'Notify DBA'; Voeg ook een disk-space monitor toe zodat je ruimteproblemen vóór bent.

Example log output

2026-05-11 08:14:03.22 spid28s     Error: 9001, Severity: 21, State: 5.2026-05-11 08:14:03.22 spid28s     The log for database 'yourdb' is not available. Check the event log for related error messages. Resolve any errors and restart the database.2026-05-11 08:14:03.23 spid28s     Error: 17207, Severity: 16, State: 1. FileMgr::StartLogFiles: Operating system error 2(The system cannot find the file specified.) occurred while creating or opening file 'D:\SQLLog\yourdb_log.ldf'.

Frequently asked questions

SQL Server error 9001 fix — hoe herstel ik de database zo snel mogelijk?

De snelste weg met behoud van data is een restore vanuit je meest recente full backup plus de beschikbare log backups. Als je Ola Hallengren of een native SQL Server backup gebruikt, check eerst welke bestanden beschikbaar zijn via msdb.dbo.backupset. Is er geen bruikbare backup, dan is DBCC CHECKDB met REPAIR_ALLOW_DATA_LOSS de noodoplossing — maar verwacht dataverlies van transacties die nog niet waren gecommit op het moment van de failure.

Kan SQL Server error 9001 vanzelf weggaan na een herstart?

Soms wel: als de oorzaak een tijdelijk vergrendeld bestand was (bijv. door een backup-agent of AV-scan), kan SQL Server na herstart het log weer openen en de database succesvol recoveren. Maar als het logbestand écht weg is of de schijf kapot is, lost een herstart niets op — de database blijft in SUSPECT of RECOVERY_PENDING state. Bekijk het SQL Server errorlog direct na de herstart om te bepalen of recovery is geslaagd.

Mijn ADF-pipeline geeft 'Login failed' of 'Cannot open database' — is dat ook error 9001?

Dat kan. Wanneer SQL Server de database offline plaatst vanwege error 9001, zien clients vaak een generieke 'Cannot open database' of connectiefout in plaats van de ruwe 9001-code. Check het SQL Server errorlog (EXEC xp_readerrorlog 0, 1, N'9001') om te bevestigen. In ADF zie je de 9001-code terug in de inner exception van de activiteitslog, niet altijd in het hoofdfoutbericht.

Hoe voorkom ik error 9001 in de toekomst?

Drie maatregelen maken het grootste verschil: (1) sla logbestanden op op een volume met hardware-redundantie (RAID 10 of Azure Premium SSD met LRS/ZRS); (2) monitor beschikbare schijfruimte en stel een alert in zodat je weet wanneer het volume boven de 80% komt; (3) sluit SQL Server data- en log-directories uit van real-time AV-scanning. Combineer dit met regelmatige full + log backups zodat je een restore-pad hebt als het toch misgaat.

Source · learn.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-9001-database-engine-error