Comments on: A Primer on Log Shrinking and Truncation in SQL Server

By: Tim Poll

Tim Poll — Fri, 08 Jun 2012 02:35:55 +0000

I use the UI to perform a shrink on the transaction file, then backup the transaction file, then perform the shrink again. There is no need to change your recovery model and thus break the LSN chain. I don’t remember the specifics, but the shrink operation needs to be run twice because the first time it was run, if the new entries are being written to the log at the end of the file, not all unused space can be physically removed. However, if the shrink operation detects this, it will fill up the rest of the log file with null space (or reset the pointer). Then when a transaction backup happens, the virtual space at the end of the log file is removed. Durning the second shrink, the log file will physically shrink to its smallest size. Then you can let it grow as needed, but hopefully max out at a smaller size.

By: Seth

Seth — Thu, 17 May 2012 21:21:07 +0000

Thanks for the comment, Christian. The DBCC SHRINKFILE TRUNCATEONLY option targets the data file only, not the log file. It does not apply if you are using DBCC SHRINKFILE on a transaction log file. The MSDN Library says:

TRUNCATEONLY
Releases all free space at the end of the file to the operating system but does not perform any page movement inside the file. The data file is shrunk only to the last allocated extent.
TRUNCATEONLY is applicable only to data files.

http://msdn.microsoft.com/en-us/library/ms189493.aspx

By: Christian Tarnutzer

Christian Tarnutzer — Tue, 24 Apr 2012 10:16:28 +0000

Nice and small Primer, Seth!
Still, there could be an addition: Why not use TRUNCATEONLY in the DBCC command? It truncates just back to the point of the last log backup (or the given size, if that’s reached before) and does not need a switch to SIMPLE recovery, thus not breaking the LSN chain:

USE AdventureWorks
GO
DBCC SHRINKFILE (AdventureWorks_Log, 10, TRUNCATEONLY)

Important is to run this command after a log backup and best after a checkpoint. Like this you are sure that the log contains as less virtual log files as possible. But be aware that if you truncate the log too much, it will have to grow right after this operation. And logfile growth in FULL recovery needs time and therefore slows down transactions on the database