Your SQL Server MDF File Is Corrupted — Here Is How to Fix It

An MDF file (Master Database File) is the primary data file for a Microsoft SQL Server database — it stores all tables, views, stored procedures, and user data. When an MDF file becomes corrupted, the database may go offline, refuse to attach, or return errors during queries.

This guide covers every repair method, from built-in SQL Server commands to specialized third-party tools.

Part 1. Understanding MDF File Corruption

MDF corruption can happen for several reasons. Knowing the cause helps you choose the right repair method.

Common causes of MDF corruption:

• Improper SQL Server shutdown — power loss or crash during a write operation leaves pages in an inconsistent state
• Disk hardware failure — bad sectors on the drive hosting the MDF file cause read/write errors
• File system errors — NTFS corruption on the host volume damages the MDF container
• Transaction log (LDF) mismatch — the LDF file is missing or does not match the MDF, causing SQL Server to refuse the attach
• Ransomware or malware — partial encryption of database files

💡 Tip: Before attempting any repair, make a bit-for-bit copy of the corrupted MDF and LDF files. Use Robocopy or ddrescue to create the backup. All repair attempts should be made on the copy, never the original.

Part 2. Using DBCC CHECKDB — The First Step

DBCC CHECKDB is SQL Server's built-in database integrity checker and the standard first step for any MDF corruption issue.

Step 1 — Check the database for errors:

USE master;
GO
DBCC CHECKDB ('YourDatabaseName') WITH NO_INFOMSGS, ALL_ERRORMSGS;
GO

Review the output carefully. DBCC reports errors at the page, extent, and table level. Note the error numbers — they determine which repair level to attempt.

Step 2 — Set the database to SINGLE_USER mode:

ALTER DATABASE YourDatabaseName SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO

Step 3 — Run repair (choose one level):

DBCC CHECKDB ('YourDatabaseName', REPAIR_REBUILD);
GO
-- If the above fails, escalate to:
DBCC CHECKDB ('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
GO

Step 4 — Return to MULTI_USER mode:

ALTER DATABASE YourDatabaseName SET MULTI_USER;
GO

⚠️ Important: REPAIR_ALLOW_DATA_LOSS is a last resort. It may delete corrupted pages permanently, removing data from affected tables. Always restore from a backup if one is available before using this option.

🗣️ r/SQLServer user: "DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS got our database back online, but we lost about 200 rows from one table. Acceptable compared to a full restore from a 3-day-old backup."

Part 3. Rebuilding the Transaction Log (LDF Missing)

If the LDF file is missing or corrupt but the MDF appears intact, SQL Server can rebuild an empty log to allow reattachment.

Method: Detach and reattach with log rebuild:

-- Detach if currently attached
EXEC sp_detach_db 'YourDatabaseName';

-- Reattach, specifying only the MDF — SQL Server creates a new LDF
CREATE DATABASE YourDatabaseName
ON (FILENAME = 'C:\Data\YourDatabase.mdf')
FOR ATTACH_REBUILD_LOG;
GO

If this fails because the MDF has dirty pages from an unclean shutdown, you may need to put the database in Emergency mode first:

ALTER DATABASE YourDatabaseName SET EMERGENCY;
ALTER DATABASE YourDatabaseName SET SINGLE_USER;
DBCC CHECKDB ('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
ALTER DATABASE YourDatabaseName SET MULTI_USER;
ALTER DATABASE YourDatabaseName SET ONLINE;

💡 Tip: After a successful emergency repair, immediately export all data using SQL Server Management Studio's Export Data Wizard to a new, clean database. The repaired database may remain fragile.

🗣️ r/sysadmin user: "The ATTACH_REBUILD_LOG trick saved us when a developer accidentally deleted the LDF. The MDF was fine — we just needed SQL Server to accept it without the log."

Part 4. Third-Party MDF Repair Tools

When DBCC CHECKDB cannot repair an MDF file — especially if SQL Server refuses to even open it — third-party tools can parse MDF files directly at the binary level, bypassing SQL Server's engine.

Most commonly recommended tools:

• Stellar Repair for MS SQL — widely used; recovers tables, views, stored procedures, triggers, and indexes even from heavily corrupted files; supports SQL Server 2005–2022
• ApexSQL Recover — specializes in recovering data from deleted, dropped, and corrupt databases; also reads transaction logs
• SysTools SQL Recovery — handles MDF files where SQL Server cannot attach at all

Typical third-party repair workflow:

1. Install the repair tool on a machine with SQL Server Management Studio (SSMS) installed
2. Open the corrupted MDF file directly in the tool — no SQL Server attachment required
3. Preview recovered objects (tables, rows, stored procedures)
4. Export recovered data to a live SQL Server instance or as SQL scripts

Part 5. Recovering a Deleted MDF File With Ritridata

If your MDF file was not corrupted but was accidentally deleted — by a script, a cleanup task, or human error — the file can often be recovered from disk before it is overwritten.

Ritridata scans the disk at the sector level to find deleted file data. MDF files are large binary files with distinct headers, making them good candidates for deep scan recovery.

How to recover a deleted MDF file:

1. Stop all write activity to the drive immediately — every new file written risks overwriting MDF data
2. Install Ritridata on a different drive, not the one containing the deleted MDF
3. Run a Deep Scan on the volume where the database files were stored
4. Filter results by .mdf extension — Ritridata identifies database file headers
5. Recover the MDF (and LDF if also deleted) to a different drive
6. Attach in SQL Server Management Studio and verify integrity with DBCC CHECKDB

💡 Tip: Ritridata's free scan shows you recoverable files before any purchase. Run the scan immediately to confirm the MDF data is still present on the disk before it is overwritten.

FAQ

Q: What is the difference between an MDF file and an LDF file? The MDF file is the primary SQL Server data file — it contains all the database objects and user data. The LDF file is the transaction log — it records all uncommitted and recent committed transactions. Both are needed to bring a database fully online, though SQL Server can rebuild a missing LDF in some scenarios.

Q: Can I open an MDF file without SQL Server? Not directly — MDF files are proprietary binary format. Third-party tools like Stellar Repair for MS SQL can parse MDF files without a running SQL Server instance, which is useful when the server itself is unavailable or the file is too corrupt to attach.

Q: What does "database in SUSPECT mode" mean? SQL Server marks a database as SUSPECT when it cannot complete the recovery process during startup — typically due to transaction log issues, corruption, or a missing data file. The database remains inaccessible until the underlying issue is resolved.

Q: Is DBCC CHECKDB safe to run on a production database? Running DBCC CHECKDB in read-only mode (without a REPAIR option) is safe and can be run on a live database. The REPAIR options require SINGLE_USER exclusive mode and carry data loss risk — always use these on a copy or during a maintenance window.

Q: What if my MDF file is from a newer version of SQL Server than I have installed? SQL Server does not support backward compatibility for MDF files — you cannot attach an MDF from SQL Server 2022 to SQL Server 2019. You need an instance of the same version or newer to open the file. Third-party tools may sometimes read across versions.

Q: How do I prevent MDF corruption in the future? Use SQL Server's Instant File Initialization, enable Write-Ahead Logging correctly, host MDF files on RAID 1 or RAID 10 arrays, schedule regular DBCC CHECKDB runs, and back up both MDF and LDF files together. Consider placing the SQL Server data directory on a UPS-protected storage system.

References

• Microsoft Docs — DBCC CHECKDB (Transact-SQL)
• Microsoft Docs — Database Attach and Detach
• Stellar Repair for MS SQL
• ApexSQL Recover
• Ritridata — Data Recovery Software