Large Transaction Log files in SQL Server 2008

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:

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.

Comments (6)


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.



This article explains a little more about transaction log backups in the FULL recovery model if anyone is interested.

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.
Awarded 2008
Awarded 2008

I would never recommend this route to shrink a transaction log.
Mark WillsTopic Advisor
Distinguished Expert 2018

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:

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 :

View More

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.