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

by

Troubleshooting Guide: SQL Server Error 3406 — “%d transactions rolled forward in database ‘%.*ls’ (%d:%d)”

Why This Error Happens

This message appears during the REDO phase of database recovery, when SQL Server replays (rolls forward) committed transactions from the transaction log to bring the database back to a consistent state after a restart, failover, or crash. It is logged as part of normal crash recovery or when a database transitions out of RESTORING/SUSPECT state, and is not an indicator of corruption or failure by itself. However, if it appears unexpectedly or repeatedly, it may point to an underlying issue such as an unclean shutdown, storage I/O interruption, or an Availability Group failover forcing redo on the secondary replica.

Step-by-Step Resolution Guide

Step 1: Confirm the Message Is Informational Only

  • Check the SQL Server Error Log via EXEC sp_readerrorlog; or open it directly from C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\Log\ERRORLOG.
  • Verify Error 3406 is immediately followed by messages like “Recovery is complete” and no severity 16+ errors are logged alongside it.
  • If no further errors follow, treat this as an informational log entry generated during routine recovery — no action required.

Step 2: Investigate the Root Cause of the Restart or Failover

  • Check Windows Event Viewer under Windows Logs > System for unexpected shutdowns, power events, or storage driver errors around the timestamp of the message.
  • Review SQL Server Error Log for prior entries such as “The log for database ‘%s’ is not available” or “SQL Server is terminating” to identify if the restart was crash-induced or planned.
  • If using Always On Availability Groups, check AG Dashboard in SSMS or sys.dm_hadr_database_replica_states to confirm if a failover triggered the redo.

Step 3: Validate Disk and Storage Health

  • Run chkdsk C:\ /f (or the relevant data/log drive) on Windows Server 2025 to rule out underlying disk corruption.
  • Check Storage Spaces Direct (S2D) or SAN multipath logs if running on clustered Windows Server 2025 infrastructure, as transient I/O timeouts often precede forced recovery.
  • Use sqlcmd -Q "DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS, ALL_ERRORMSGS;" to confirm database integrity post-recovery.

Step 4: Monitor Transaction Log Growth and VLF Count

  • Excessive rolled-forward transactions can indicate a transaction log that is too large or has high VLF (Virtual Log File) fragmentation, slowing recovery time.
  • Run DBCC LOGINFO('YourDatabaseName'); to review VLF count; if it exceeds 1,000, consider shrinking and regrowing the log in fixed increments via ALTER DATABASE ... MODIFY FILE.
  • Set log file autogrowth to a fixed MB value (e.g., 512MB) instead of a percentage to prevent fragmentation going forward.

Alternative or Verification Steps

  • Confirm the database is online and healthy by running SELECT name, state_desc FROM sys.databases WHERE name = 'YourDatabaseName'; — state should read ONLINE.
  • If Error 3406 recurs frequently without a clear restart/failover trigger, enable trace flag 3004 and 3605 temporarily to get more verbose recovery logging, and escalate to Microsoft CSS if paired with any 823/824 I/O errors.