What Is a SQL Server .ldf FileAn .ldf File Is the SQL Server Transaction Log
Every SQL Server database keeps a transaction log in an .ldf file. It records each change to the data as it happens. This guide explains what is inside an .ldf, why the log matters and how to read one with or without SQL Server.
The Basics
An .ldf file is the transaction log that pairs with a database. The extension marks a log file, often written out as Log Database File, created for each database. Where the MDF holds the current data, the .ldf holds the running record of every change made to it. SQL Server writes to the log first, then to the data, which is how a database survives a crash. A few other programs use .ldf for their own logs, so the context here is SQL Server.
A transaction log is a stream of log records, not a table you can browse. SQL Server splits the file into virtual log files and fills them in a ring. Each record has a log sequence number that fixes its place in the order, an operation type and a pointer to the table and page it changed. Many records also keep an image of the row before and after the change, which is how a reader can show the value that was written or removed. Put the records back in order and you have the history of the database.
Before SQL Server changes a row in the data file, it writes a record of that change to the log. This is called write-ahead logging. It is why the log holds a complete trail. Each record names an operation like insert or delete, the table it touched and the transaction it belonged to.
Every change leaves a mark
Because the log is written first, a change reaches it even if the row is later removed. Univik reads those records at a low level, so you can see what ran against the database without a server in the loop.
The log is more than a history you can read. SQL Server leans on it to keep the database correct and recoverable. Four jobs stand out.
How large the .ldf grows depends on the recovery model. The model sets when the log can reuse its own space, a step called truncation. Truncation frees room inside the file. It does not shrink the file on disk.
When the log runs away
Most runaway .ldf files come from the full model with no log backups. A long transaction that holds the log open can do it too. Take regular log backups or switch to the simple model, then shrink the file with DBCC SHRINKFILE if it is still too large.
There are two paths to the log. Query it through SQL Server or read it straight from the file.
With SQL Server
SQL Server reads its own log through the undocumented functions fn_dblog and fn_dump_dblog, with DBCC LOGINFO to list the virtual log files. They need a running instance and return raw records that take real effort to decode.
Without SQL Server
Univik opens the .ldf as a file and decodes the records for you. It lays out the operations, the tables and the order, with no instance to stand up first.
The log answers questions the live data cannot. Reading it turns a binary file into a clear account of what happened.
Audit Trail
See which operations ran against the database and in what order.
Recent Deletes
A deleted row is logged before its space is reused, so it can still be read.
Investigation
Trace a change back to the transaction that made it.
Activity Review
Understand what a database has been doing over a span of time.
The Tools
Univik reads the log as a file, so the change history is yours even when no server is running.
SQL LDF Viewer
Open an .ldf and read the log records: which operations ran, on which tables, in what order. Free, with no SQL Server.
View a Transaction LogSQL Log Analyzer
Read the log for an investigation and build a court-ready forensic report, with evidence hashes and activity charts.
Analyze the LogSQL Database Recovery
The log shows what changed. To rebuild the data itself from a database that will not attach, read the MDF with SQL Database Recovery.
Recover a Database
Help & Support
Common questions about SQL Server transaction log files.
A .ldf file is a SQL Server transaction log. Every database has at least one. It records each change to the data before that change is written to the MDF, so the server can recover after a crash.
Use a tool that reads the log as a file. Univik opens an .ldf directly, decodes the log records and shows the operations behind them, with no SQL Server and no attach.
No. An .ldf is a binary transaction log, not text, so Notepad or Excel only show scrambled characters. You need a tool that decodes the log. Inside SQL Server, the fn_dblog function does the same job.
The log holds a stream of log records, each with a sequence number, an operation type and the table it touched. Read in order, those records are the full history of changes to the database.
Often yes. A delete is written to the log as a record before the space is reused, so a recent delete can still be read from the .ldf. Univik surfaces these operations for review.
The log grows with heavy activity and long transactions. In the full recovery model it also grows when the log is not backed up. Backing up the log frees its space to be reused. You can then shrink the file with DBCC SHRINKFILE once the cause is fixed.
No. A database needs its log to run, to roll back and to recover, so deleting the .ldf can leave the database unable to start. Keep the log with the MDF and manage its size instead.
No. The MDF holds the live data a database uses. The .ldf holds the log of changes to that data. A database keeps both. Univik reads each one.
Yes. Univik opens the .ldf as a file and lists the log operations with no matching MDF and no server. To rebuild the data itself, pair the log with the MDF.