Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Shrinking all log files on SQL Server 2008R2


Shrinking all log files on SQL Server 2008R2

Author
Message
Igor Micev
Igor Micev
SSCarpal Tunnel
SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)

Group: General Forum Members
Points: 4488 Visits: 4943
Comments posted to this topic are about the item Shrinking all log files on SQL Server 2008R2


Igor Micev,
SQL Server developer at Seavus
www.seavus.com
Nadrek
Nadrek
Ten Centuries
Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)

Group: General Forum Members
Points: 1194 Visits: 2698
It is almost never recommended to shrink database or log files, even less likely to need them done all at once, and absolutely not in a scheduled job. Shrinking log files creates filesystem level fragmentation as the logs keep growing again. If your autogrow settings are too small, this can be a serious problem - see Kimberly Tripp's article http://www.sqlskills.com/blogs/kimberly/post/Transaction-Log-VLFs-too-many-or-too-few.aspx

Additionally, this shrink doesn't account for Transaction log backup first for non-simple mode databases or the repeated cycles often required to move the active log VLF away from the middle or end.
Perry Whittle
Perry Whittle
SSChampion
SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)

Group: General Forum Members
Points: 10914 Visits: 16805
OK, you're joking right??
Firstly, TRUNCATEONLY does not apply to T-log files!
A wholesale shrink of all log files on the instance, and you believe this will be beneficial?
What do you do for an encore, shrink the data files then rebuild the indexes?

Incidentally, Do you carry out index maintenance on your SQL Server instance?

-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs" ;-)
Nadrek
Nadrek
Ten Centuries
Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)

Group: General Forum Members
Points: 1194 Visits: 2698
Perry, excellent point on TRUNCATEONLY only applying to data files (and all arguments about 'do not shrink' apply to data files just as well as to log files).

For anyone wondering, here's a reference: http://technet.microsoft.com/en-us/library/ms189493.aspx
Perry Whittle
Perry Whittle
SSChampion
SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)

Group: General Forum Members
Points: 10914 Visits: 16805
Furthermore, the script targets files with ".ldf" extension. What happens if a DBA creates a database and gives one of the data files on a database the ".ldf" extension ;-)

At least filter the files in sys.master_files by their type (0 = rows, 1 = log)

-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs" ;-)
Igor Micev
Igor Micev
SSCarpal Tunnel
SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)

Group: General Forum Members
Points: 4488 Visits: 4943
Nadrek (11/2/2012)
It is almost never recommended to shrink database or log files, even less likely to need them done all at once, and absolutely not in a scheduled job. Shrinking log files creates filesystem level fragmentation as the logs keep growing again. If your autogrow settings are too small, this can be a serious problem - see Kimberly Tripp's article http://www.sqlskills.com/blogs/kimberly/post/Transaction-Log-VLFs-too-many-or-too-few.aspx

Additionally, this shrink doesn't account for Transaction log backup first for non-simple mode databases or the repeated cycles often required to move the active log VLF away from the middle or end.



Hi All

The idea of this script is to be used on testing and developing environments. Of course you should never shrink LOG files on production environment, except in emergent cases.

I here want to share my experience with this, because parts of my work is restoring databases every day, and making massive inserts and updates, so that the LOG file can grow too much ... and I find this script useful. Once again it's purpose was not intended for production environments.

Thank you
IgorMi


Igor Micev,
SQL Server developer at Seavus
www.seavus.com
Igor Micev
Igor Micev
SSCarpal Tunnel
SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)

Group: General Forum Members
Points: 4488 Visits: 4943
Perry Whittle (11/2/2012)
OK, you're joking right??
Firstly, TRUNCATEONLY does not apply to T-log files!
A wholesale shrink of all log files on the instance, and you believe this will be beneficial?
What do you do for an encore, shrink the data files then rebuild the indexes?

Incidentally, Do you carry out index maintenance on your SQL Server instance?


Hi Perry,

Of course it is not for production. I needed it on test and development envs and just made a search and didn't find something useful and did it myself, so I'm just sharing it and appointing that this is recommended only on testing and dev instances.

Regards
IgorMi


Igor Micev,
SQL Server developer at Seavus
www.seavus.com
Iwas Bornready
Iwas Bornready
SSCrazy Eights
SSCrazy Eights (9.8K reputation)SSCrazy Eights (9.8K reputation)SSCrazy Eights (9.8K reputation)SSCrazy Eights (9.8K reputation)SSCrazy Eights (9.8K reputation)SSCrazy Eights (9.8K reputation)SSCrazy Eights (9.8K reputation)SSCrazy Eights (9.8K reputation)

Group: General Forum Members
Points: 9842 Visits: 885
We have a use for this in our testing environment. Thanks.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search