How to fix SQL Server error 5173 (files do not match the primary file)
This means a file you are attaching or starting does not belong to the same database as the primary MDF. Usually the log file is from a different database or an older copy. The fix is to attach the correct matching files, or rebuild the log if the original is gone. Jump to your situation below or work through the methods in order.
By Neeraj Singh ~7 min Updated Jun 2026 93% found this helpful
Error message
Error: 5173, Severity: 16, State: 1. One or more files do not match the primary file of the database. Log file 'YourDB_log.ldf' does not match the primary file. It may be from a different database or the log may have been rebuilt previously.
Summary
Error 5173 means one of the files SQL Server is trying to use, almost always the LDF log file or a secondary NDF, does not belong to the same database as the primary MDF. Each data and log file carries internal identifiers, and when those do not line up SQL Server refuses to attach or start the database to avoid mixing files from different databases. It usually happens when files were copied at different times, mixed from separate databases or backups, or the log was rebuilt previously. The fix is to attach the MDF together with its own matching LDF. If the original log is missing or mismatched and the database was shut down cleanly, you can rebuild the log on attach with ATTACH_REBUILD_LOG. When the files are corrupt, restore from a known-good backup instead.
What this error means
Error 5173 (Severity 16) is raised during an attach, a restore or database startup when the files presented do not form a matching set. The primary MDF records which log and secondary files belong to it, and each file stamps an internal identifier. If the LDF or an NDF carries a different stamp, SQL Server reports 5173 and leaves the database in RECOVERY_PENDING rather than risk corrupting it.
The trigger is almost always that the files were not captured together. Copying a live MDF and LDF at slightly different times, grabbing a log from a different database, or reusing a log that was rebuilt earlier all produce a mismatch. Because this is a file-pairing problem, the cure is to supply the correct pair, not to repair the database, unless the mismatch is actually caused by corruption.
Common causes
The LDF log file is from a different database or an older copy of this one.
The MDF and LDF were copied at different times, so their internal stamps differ.
The log was previously rebuilt, so it no longer matches the data file.
A secondary NDF file belongs to another database or backup set.
A half-finished copy or restore left a mismatched set of files.
Corruption altered a file header, which can also raise error 824 alongside 5173.
The wrong LDF path was supplied when attaching the MDF.
Expert insight
“5173 is almost never a corruption problem, it is a paperwork problem. Someone copied the MDF and LDF at different moments, or grabbed the log from the wrong folder, and now the stamps inside the files do not agree. The first thing I do is read the ERRORLOG, because it names the exact file that does not match. If I have the original matching log, I attach the pair and I am done. If the log is genuinely lost and the database was closed cleanly, ATTACH_REBUILD_LOG makes a fresh one. And this is the moment I remind people that copying files is not a backup, BACKUP and RESTORE keep the set together so you never see 5173.”
Manager, Tech Support & Operations · 19+ years fixing Windows and system errors
✓ How to fix it
Method 1
Read the ERRORLOG to see which file mismatches
1Open the SQL Server ERRORLOG and find the 5173 line. It names the exact file that does not match, for example the LDF.
2From a query window you can read it with:
USE master;
EXEC xp_readerrorlog 0, 1, N'do not match';
3Knowing whether it is the log or a secondary file tells you which method to use.
Method 2
Attach the correct matching files
1Gather the MDF together with its own LDF, captured at the same time from the same database, and attach them together:
CREATE DATABASE [YourDB] ON
(FILENAME = 'D:\Data\YourDB.mdf'),
(FILENAME = 'D:\Data\YourDB_log.ldf')
FOR ATTACH;
2Make sure the LDF path is the real matching log, not a leftover from another database.
3If the files match, the database attaches and comes online cleanly.
Method 3
Rebuild the log if the original is missing or mismatched
1If the log is lost or will not match and the database was shut down cleanly, attach the data file alone and let SQL Server build a new log:
CREATE DATABASE [YourDB] ON
(FILENAME = 'D:\Data\YourDB.mdf')
FOR ATTACH_REBUILD_LOG;
2This discards the old log and creates a fresh one, so any transactions still in the old log are gone.
3If the database was not shut down cleanly, this will fail, in which case restore from backup.
Method 4
Or rebuild the log from the SSMS attach dialog
1In SQL Server Management Studio, right-click Databases and choose Attach, then add the MDF.
2In the database details grid, select the log row and click Remove so SQL Server recreates the log on attach.
3Click OK. This is the point-and-click equivalent of ATTACH_REBUILD_LOG.
Method 5
Restore from a known-good backup
1If the files are corrupt rather than simply mismatched, a restore is the reliable fix. Restore the full backup then the log chain.
2This sidesteps the file-pairing problem entirely because the backup already contains a matching set.
3Run DBCC CHECKDB after the restore to confirm consistency.
Method 6
If 5173 hits an existing database at startup
1When 5173 appears for a system or user database as SQL Server starts, that database is left in RECOVERY_PENDING.
2Put it in emergency mode so you can read it, then copy out critical data before rebuilding or restoring:
ALTER DATABASE [YourDB] SET EMERGENCY;
3For a damaged system database such as msdb, restore it from backup, or rebuild system databases using SQL Server setup.
Method 7
Verify the database after attach
1Once attached, run a full consistency check to be sure nothing else is wrong:
DBCC CHECKDB ('YourDB') WITH NO_INFOMSGS, ALL_ERRORMSGS;
2Confirm the database is ONLINE and the application can connect.
3Take a fresh full backup straight away so you have a clean, matching set.
Copying live MDF and LDF files is not a backup, because the two files are rarely captured at the exact same instant and the mismatch is what produces 5173. Use BACKUP DATABASE and BACKUP LOG instead, then RESTORE, so the data and log always belong to the same set. Keep each MDF with its own LDF and never reuse a log file from another database.
Frequently asked questions
What does SQL Server error 5173 mean?
It means a file you are attaching or starting, usually the LDF, does not belong to the same database as the primary MDF. Their internal identifiers do not match, so SQL Server refuses to attach the set.
Why does my log file not match the primary file?
Usually because the MDF and LDF were copied at different times, the log came from a different database, or the log was rebuilt previously. Each file stamps an identifier, and a mismatch triggers 5173.
How do I attach a database when the log is missing?
Attach the data file alone with FOR ATTACH_REBUILD_LOG, or in the SSMS attach dialog remove the log row. SQL Server then builds a fresh log, provided the database was shut down cleanly.
Will rebuilding the log lose data?
It discards any transactions still held in the old log, so anything not yet written to the data file is lost. If the database was shut down cleanly there is usually nothing pending.
Can I just restore from backup instead?
Yes, and it is the safest option when the files are corrupt. A backup already contains a matching data and log set, so restoring avoids the file-pairing problem entirely.
How do I prevent error 5173?
Never copy live MDF and LDF files as a backup. Use BACKUP and RESTORE so the files always match, and keep each MDF together with its own log file.
Still not working?
If the correct log truly cannot be found and ATTACH_REBUILD_LOG fails because the database was not shut down cleanly, the database is in an inconsistent state and a backup restore is the dependable path. For a damaged system database, rebuilding system databases with SQL Server setup may be required. You can also submit your error to us for a tailored fix.
