Auto shrink is just pure evil

If you don’t agree with the above statement please keep reading.  I’m write, and it’s important, I promise.

In order for the auto-shrink feature to be really effective it has to move data from the end of the file to the middle/front of the file so that it can chop off the tail end of the database file.  This causes extra load to be placed on the disk, and on the CPU as it is identifying the data pages which can be moved, then moves them.

It also causes extra fragmentation to happen within the database as the shrink operation does not preserve the fragmentation state of the indexes within the database.  Because of this the worst time to shrink a database is write after the indexes have been rebuilt.  Because of the extra space that is needed to rebuild indexes this is probably also the most common time to shrink a database on a regular basis.

My favorite reason to not shrink a database is listed directly in Books OnLine under the “Shrinking a Database” heading.  Under the Best Practices topic it says “Unless you have a specific requirement, do not set the AUTO_SHRINK database option to ON.”.

So go and turn your AUTO_SHRINK settings to off like they should be and quit worrying if the hard drive icon in the My Computer window shows that it’s full.  Worry about about how much free space is within the database files, not the free space on the disk.   Fill the disk already.  It’s fun, and all the cool kids are doing it.



2 Responses

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trust DCAC with your data

Your data systems may be treading water today, but are they prepared for the next phase of your business growth?