views:

2210

answers:

4

I have had a few problems with log files growing too big on my SQL Servers (2000). Microsoft doesn't recommend using auto shrink for log files, but since it is a feature it must be useful in some scenarios. Does anyone know when is proper to use the auto shrink property?

A: 

I used to use it when we had a demo version of a huge database that took up a lot of space on the laptop, so we used it to keep the size down.

The key is to use it only when the data is basically throw away.

You should truncate the logs periodically as a part of your backup strategy.

Charles Graham
In a production database that is transactional, you should not truncate the log, you should back it up.
HLGEM
It does not throw away any data
StingyJack
You can truncate the log if keeing size down is important, as long as it works with your backup scheme. That is, you do a full backup, truncate, and then backup again when there is little to no activity.
Charles Graham
I know that it does not throw away any data. What I meant is that it should only be used when data integrity is not important.
Charles Graham
A: 

My take on this is that auto-shrink is useful when you have many fairly small databases that frequently get larger due to added data, and then have a lot of empty space afterwards. You also need to not mind that the files will be fragmented on the disk when they frequently grow and shrink. I'd never use auto-shrink on a critical database or one larger than 2 GB, as you never know when the shrink operation will kick in, and access to the database will be blocked until the shrink has completed.

Jim McLeod
+4  A: 

Your problem is not that you need to autoshrink periodically but that you need to backup the log files periodically. (We back ours up every 15 minutes.) Backing up the database itself is not sufficient, you must do the log as well. If you do not back up the transaction log, it will grow until it takes up all the space on the drive. If you back it up, it frees the space to be reused (you will still probably need to shrink after the first backup to get the log down to a more reasonable size). If you don't need to be able torecover from transactions (which you should need to be able to do unless your entire database consists of tables that are loaded from another source and can easily be re-loaded.), then set your log to simlpe recovery mode.

One reason why autoshrinking isn't so good an idea is that you will be growing the transaction log frequently which slows down performance. IF you back up the log, one you get to a relatively stable size (the amount of space normally used by the transaction log in the time period between backups), then the log will only need to grow occasionally if there are an unusually heavy amount fo transactions.

HLGEM
A: 

You should never have autoshrink turned on. It causes performance degradation in several ways. The file-system and indexes become fragmented and it is very resource intensive. It is also not necessary if you manage your backups correctly.

Read this answer from Paul Randal on Server Fault and Just Say No To Auto-Shrink!!

Alex Angas