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.