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

by

Troubleshooting Guide: SQL Server Error 5182 — “New Log File Was Created”

Why This Error Happens

Error 5182 is typically raised during database recovery when SQL Server detects that a transaction log file is missing, corrupted, or has an invalid Log Sequence Number (LSN) chain, forcing the engine to create a new log file to replace the inconsistent one. This often occurs after an improper shutdown, a failed storage subsystem, forcibly detaching a database without flushing transactions, or manually deleting/replacing the .ldf file while the database was offline. Because the newly created log file breaks continuity with prior transactions, the database may be left in a state where point-in-time recovery or log-chain-dependent operations (like replication or Always On) are no longer possible.

Step-by-Step Resolution Guide

Step 1: Identify the Affected Database and Confirm Log Discontinuity

  • Check the SQL Server Error Log (via SSMS > Management > SQL Server Logs, or xp_readerrorlog) for the exact message text referencing error 5182 and the database name.
  • Run DBCC CHECKDB ('YourDatabaseName') WITH NO_INFOREPAIR to confirm whether log/data consistency issues exist beyond the log file recreation.
  • Note whether the database is currently in SUSPECT, RECOVERY_PENDING, or EMERGENCY mode via SELECT name, state_desc FROM sys.databases;.

Step 2: Restore From a Verified Backup (Preferred Fix)

  • If a recent full backup and subsequent log backups exist, restore the full backup first: RESTORE DATABASE YourDatabaseName FROM DISK = 'C:\Backups\YourDatabaseName.bak' WITH NORECOVERY;
  • Apply all available transaction log backups in sequence using RESTORE LOG ... WITH NORECOVERY, then finish with WITH RECOVERY on the last one.
  • This avoids relying on the auto-created log file and restores full LSN continuity, which is the only fully supported fix for broken log chains.

Step 3: Rebuild the Log File if No Backup Is Available

  • Set the database to emergency mode: ALTER DATABASE YourDatabaseName SET EMERGENCY;
  • Put the database in single-user mode: ALTER DATABASE YourDatabaseName SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
  • Run DBCC CHECKDB ('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS); — note this may cause data loss since it rebuilds the log chain from scratch.
  • Return the database to multi-user mode: ALTER DATABASE YourDatabaseName SET MULTI_USER;

Step 4: Check Underlying Storage and Permissions

  • On Windows Server 2025 / Windows 11, verify the SQL Server service account has Full Control on the data/log directory (typically C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\DATA\).
  • Run chkdsk C: /f (or the relevant drive) during a maintenance window to rule out underlying disk corruption that triggered the original log failure.
  • Review Windows Event Viewer (Applications and Services Logs > Windows > Ntfs/Disk) for storage-related warnings around the time of the incident.

Alternative or Verification Steps

  • After recovery, run DBCC LOGINFO('YourDatabaseName') and DBCC CHECKDB to confirm the log file is healthy and there are no remaining consistency errors.
  • If REPAIRALLOWDATA_LOSS was used, immediately take a fresh full backup and audit affected tables for missing or inconsistent data, since the rebuilt log file breaks the original backup chain going forward.