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

by

Troubleshooting Guide: SQL Server Error 5113

Why This Error Happens

Error 5113 occurs when SQL Server attempts to rebuild a transaction log file but detects that the database was not cleanly shut down — specifically, there were open transactions or active user connections at the time of shutdown. This typically happens after a forced service stop, an unexpected server crash, or a hardware failure that prevents SQL Server from properly flushing and closing the log file. Because the log file’s LSN (Log Sequence Number) chain is incomplete, SQL Server refuses to rebuild it automatically to avoid data corruption, and manual intervention using ATTACH_REBUILD_LOG or emergency mode is required.

Step-by-Step Resolution Guide

Step 1: Verify the Scope of the Problem

  • Open SQL Server Management Studio (SSMS) or a query window and attempt to bring the database online using ALTER DATABASE [YourDB] SET ONLINE;
  • Check the SQL Server Error Log (default path: C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\Log\ERRORLOG) for confirmation of Error 5113 alongside the database name.
  • Confirm whether a valid, recent full backup and transaction log backup exist before proceeding — rebuilding the log breaks the backup chain.

Step 2: Attempt Database Attach with Log Rebuild

  • Detach the database first if it is currently attached but inaccessible, using EXEC sp_detach_db 'YourDB';
  • Run the following T-SQL command to force a rebuild of the log:
  CREATE DATABASE YourDB ON 
  (FILENAME = 'C:\SQLData\YourDB.mdf') 
  FOR ATTACH_REBUILD_LOG;
  • Ensure the SQL Server service account has full Read/Write/Modify permissions on the folder containing the .mdf file (right-click folder → Properties → Security → Edit).

Step 3: Use Emergency Mode if Attach Fails

  • If ATTACH_REBUILD_LOG fails, place the database into emergency mode:
  ALTER DATABASE YourDB SET EMERGENCY;
  ALTER DATABASE YourDB SET SINGLE_USER;
  DBCC CHECKDB (YourDB, REPAIR_ALLOW_DATA_LOSS);
  ALTER DATABASE YourDB SET MULTI_USER;
  • Run this only after confirming no usable backups exist, as REPAIR_ALLOW_DATA_LOSS can discard corrupted transactions.

Step 4: Restore From Backup (Preferred if Available)

  • If a valid backup chain exists, restore the full backup followed by differential/log backups using RESTORE DATABASE and RESTORE LOG commands with NORECOVERY, finishing with WITH RECOVERY.
  • This avoids the risk of data loss associated with forced log rebuilds.

Alternative or Verification Steps

  • After recovery, run DBCC CHECKDB (YourDB) WITH NO_INFOMSGS, ALL_ERRORMSGS; to confirm there is no remaining corruption.
  • If the database comes online but data appears inconsistent, immediately take a full backup and compare row counts on critical tables against your last known-good backup to assess data loss.