How to fix Error 3619 on Windows Server 2025 / Windows 11

by

Troubleshooting Guide: SQL Server Error 3619 – Checkpoint Record Could Not Be Written (Log Full)

Why This Error Happens

This error occurs when the transaction log for a database has filled completely, leaving no space for SQL Server to write a checkpoint record. This typically happens because the log file has hit its configured MAXSIZE limit, the disk volume hosting the .ldf file is out of physical space, or long-running/uncommitted transactions are preventing log truncation. In some cases, a corrupted or misconfigured database with the recovery model set to FULL without regular log backups can cause the log to grow unchecked until it exhausts available space.

Step-by-Step Resolution Guide

Step 1: Identify the Log Space Usage and Root Cause

  • Run the following query to check log space consumption: DBCC SQLPERF(LOGSPACE);
  • Check the log_reuse_wait_desc column for the affected database using: SELECT name, log_reuse_wait_desc FROM sys.databases;
  • Common blockers include ACTIVE_TRANSACTION, LOG_BACKUP, or REPLICATION.

Step 2: Back Up the Transaction Log (If Recovery Model is FULL)

  • Navigate to SQL Server Management Studio (SSMS) or use T-SQL.
  • Execute: BACKUP LOG [YourDatabaseName] TO DISK = 'E:\SQLBackups\YourDatabaseName_Log.trn';
  • This action truncates the inactive portion of the log and frees up internal space without shrinking the physical file.

Step 3: Allocate Additional Disk Space or Expand the Log File

  • Open SSMS > Right-click the database > Properties > Files.
  • Manually increase the size of the .ldf file or adjust Autogrowth settings (recommend fixed MB growth rather than percentage to avoid fragmentation).
  • Alternatively, run: ALTER DATABASE [YourDatabaseName] MODIFY FILE (NAME = YourDB_Log, SIZE = 5GB);
  • If the OS volume (e.g., E:\) is full, move the log file to a drive with more free space using ALTER DATABASE ... MODIFY FILE with a new FILENAME path, then offline/online the DB to complete the physical move.

Step 4: Kill Long-Running Transactions Blocking Log Truncation

  • Query active sessions holding open transactions: DBCC OPENTRAN('YourDatabaseName');
  • If a runaway session is identified via sp_who2 or sys.dm_exec_requests, safely terminate it using KILL [session_id]; only after confirming it is not a critical business transaction.

Step 5: Shrink the Log File (Post-Resolution Cleanup Only)

  • Once log backups are successful and space is freed, run: DBCC SHRINKFILE(YourDB_Log, 1024);
  • Note: Do not shrink the log file as a permanent fix; use this only to reclaim disk space after addressing the root cause, as frequent shrinking causes performance-impacting fragmentation.

Alternative or Verification Steps

  • Verification: Re-run DBCC SQLPERF(LOGSPACE); to confirm the “Log Space Used (%)” has dropped significantly and attempt a test transaction (e.g., an INSERT/UPDATE) to ensure the database accepts writes without triggering Error 3619 again.
  • Alternative Fix: If the recovery model is FULL but point-in-time recovery isn’t required, consider temporarily switching to SIMPLE recovery mode (ALTER DATABASE [YourDatabaseName] SET RECOVERY SIMPLE;) to force automatic log truncation at checkpoints, though this will break the log backup chain.