[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More


Large Transaction Log files in SQL Server 2008

Published on
10,800 Points
1 Endorsement
Last Modified:
There have been several questions about Large Transaction Log Files in SQL Server 2008, and how to get rid of them when disk space has become critical. This article will explain how to disable full recovery and implement simple recovery that carries much smaller transaction log files.

Here is a recommended MS document showing proper procedures for truncating log size. I recommend you review this article before proceeding: http://msdn.microsoft.com/en-us/library/ms189085(v=SQL.100).aspx

The recovery model in SQL server is set by default for all databases to "FULL". In the full recovery model all transactions from the beginning of the database creation are kept in a file that grows along with the database file until it reaches outrages sizes. There are methods of shrinking these transaction log files but that doesn't always provide a long term solution. Full recovery is recommended so that in the event of corruption or failure the database can be recovered to the very minute the database went down. Simple recovery will only allow you to recover the database to the last backup copy of the database.

If you are okay with losing a small amount of transaction log you can switch to the simple recovery model and free up a large amount of space on your server, by following these simple steps as it worked for me:

Perform a Full Backup of the Database

Open SQL Management Studio

Browse to the database with the large transaction log file and right click the database, go to "Properties" Click on "Options" and change the recovery model to "Simple" then click "OK". You have now changed the logging from "FULL" to "SIMPLE".

In order for the log size to decrease you have to perform a checkpoint event, such as another full backup (another recommended step would be to run dbcc shrinkfile at this time). Transactions can hang and SIMPLE logging my not take place so if the database log size does not shrink as a last resort you can take the database offline and then bring it back online to enact the change as explained below:

Browse to the Database, right click, "Tasks" => "Take Offline". Then repeat the step but choose "Bring Online". You will now notice the transaction log file is significantly smaller.

Done, you have accomplished the goal of reducing the transaction log size.

In the event that you simply wanted to reduce the size of the file, but still want full recovery you can re-enable "FULL" recovery at this time.  Also worth checking the initial size allocation for your Transaction Log as explained in the Microsoft Article above.

That's all for today folks, let me know if this helps.
LVL 22

Expert Comment

This article is misleading and doesn't sufficiently explain the assumptions or, more importantly, the caveats for the advice it gives.


"In the full recovery model all transactions from the beginning of the database creation are kept in a file that grows along with the database file until it reaches outrages [sic] sizes"

This is wrong. The log file records only transactions since the last log backup / log truncation. The most common reason the size might be "outrageous" would be if it wasn't being backed up often enough. The appropriate solution for most people would be to take log backups more frequently, not to select simple recovery. This is not even mentioned in the article. The article continues:

"If you are okay with losing a small amount of transaction log..."

but the suggested course of action is to invalidate or truncate the current log no matter how much data has been or is being logged. For many people this won't be a "small" issue at all. I expect the author meant to say "if you don't need the protection of transaction log backups..." but using the word "small" suggests that this is not a very important concern.

Recommending taking the database offline is also a pretty drastic suggestion - although I guess most people will realise the implications of that.

Finally, the author says if you "still want full recovery you can re-enable FULL recovery at this time." but fails to mention that the log backup sequence is now invalid and so you are NOT protected by full recovery at this point. Until you do a full backup again you might as well still be running in Simple recovery, which is a bad place to be if you thought you were in full recovery mode.

I suppose any DBA ought to know that these things, but if they do then they wouldn't find this article at all useful.

Author Comment

Thanks for your comments, The line "If you are okay with losing a small amount of transaction log..." was actually modified by the editor prior to posting. I can see why that would be misleading since you do run the risk of losing all data back to the last full backup. It is also correct that after switching back to FULL recovery you will need to run another full backup before FULL recovery goes back into effect.

As the article state taking the database offline then bringing it back online is a last resort, sometimes transactions get stuck and a checkpoint is not sufficient to make the change. Overall the article is still useful, and the MSDN article clears up alot of these questions.

Author Comment


This article explains a little more about transaction log backups in the FULL recovery model if anyone is interested.
Acronis True Image 2019 just released!

Create a reliable backup. Make sure you always have dependable copies of your data so you can restore your entire system or individual files.

LVL 22

Expert Comment

Book Online is a good place to start reading about t-log backups.

Log truncation is automatic when you back up the log. You don't need to do anything special to set it up.
LVL 60

Expert Comment

I would never recommend this route to shrink a transaction log.
LVL 55

Expert Comment

by:Mark Wills
The article makes more sense if you were to follow the recommendations of the Author in the second paragraph :

I recommend you review this article before proceeding: http://msdn.microsoft.com/en-us/library/ms189085(v=SQL.100).aspx

It covers some of the concerns mentioned above and provides far greater / more in depth account of what the Transaction log is and does along with the links on how to manage in various conditions.

I agree by and large with some of the concerns, and the Article should be considered as a last resort, and there are other methods as described in the MSDN article.

Truncating the log and reducing the physical disk consumption are quite different. Going from FULL recovery to SIMPLE would be "if all else fails" and life is fairly critical (like transaction log has filled the disk).

Still, the first approach if you must shrink the physical size of the transaction log would be DBCC SHRINKFILE as per : http://msdn.microsoft.com/en-us/library/ms178037(v=sql.100).aspx

Featured Post

Build an E-Commerce Site with Angular 5

Learn how to build an E-Commerce site with Angular 5, a JavaScript framework used by developers to build web, desktop, and mobile applications.

Join & Write a Comment

SQL Database Recovery Software repairs the MDF & NDF Files, corrupted due to hardware related issues or software related errors. Provides preview of recovered database objects and allows saving in either MSSQL, CSV, HTML or XLS format. Ensures recov…
Stellar Phoenix SQL Database Repair software easily fixes the suspect mode issue of SQL Server database. It is a simple process to bring the database from suspect mode to normal mode. Check out the video and fix the SQL database suspect mode problem.

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month