That is some error to make the DB grow to 17GB from 300! This was your .mdf not your .ldf (log file) right?

While it is not good to be in a repeated cycle of shrink-grow-shrink-grow or even do frequent shrink databases on a production system, a one off isn’t bad in a situation like this. What I suggest you do is shrink the database FILE that needs to be shrunk, leave a healthy (up to a few years growth would be ideal, even if a guess) amount of free space in the file and then rebuild your indexes after the fact.

My database was about 300 MB a few days back. Due to an error it grew to 17GB overnight. I have fixed the problem to an extent by deleting the swollen records and database backups are in the region of 300MB again. However the mdf file still remains 17GB. Is it a good idea to shrink the database?

My concern is that this database is very small and so is the server where it stands; in relative terms 17GB (x2, production and test) is a lot of space to block and could be used more effectively otherwise.

Thanks in advance
Natasha

Thanks for the comment. I’ll give a quick response now before hitting bed. Feel free to shoot me an e-mail mike at the domain of this blog works, your e-mail address looks like a fake one to prevent spam.

I would say in this case a shrink sounds like an alright idea. I would say set the final size to the size you expect the file to be in a couple/few years if possible. This will prevent the file from having to autogrow in small chunks. While at it, I would also suggest to change the auto growth from the default 1MB, something more in line with the size of the DB. Paul and Kimberly blog about this over at their site and that link from Paul at the end of the above article is a good place to go look for more.

The goal is to avoid physical file fragmentation from lots of growths. Growths were more expensive before Instant File Initialization starting in 2005 but the effect on physical files (not index fragmentation but on disk file fragmentation) still exists.

So I would say a shrink of the file to an appropriate size is not a horrible solution. I would caution you to not shrink the database but just the data files and consider the impact of VLF fragmentation

I have a client who’s asked a question about shrinking a database. I’d be interested to get yours Mike or other people’s thoughts. Here’s the background;

The client has moved a large table to a new database and the result is that the original database file is now 75% free space (presumably they were intending to free the space up and possibly going for performance perks).

They asked my opinion of shrinking. I started writing basically that while auto or scheduled-manual shrinking is typically a bad idea, a one off will be ok, but before sending it Googled “don’t shrink sql server database” to find arguments against doing it – I came across this article.

Lets assume the growth is predictable and auto-growth settings are sensible. Do you think there would be any problem with performing a one-off shrink in this case? How about a shrink, manually setting the shrunk file size to be a little greater than 1 auto-growth unit so that an auto-grow will not immediately occur?

Index defrag is regularly performed and I’m also recommending performing a full backup first and doing this in a change window in case a restore is required.

Chris
DBA
Perth, Australia

I apologize for any confusion I may have caused with my stream of thought style and wording. I can’t speak towards Oracle as I am not as familiar with the physical file organization or the indexing structures in Oracle databases.

For SQL Server the major point I was trying to make, however, was that physical file fragmentation is bad. The Best case is that this fragmentation is handled somewhat alright by the O/S and its defragmentation processes and doesn’t end up a big deal. That was slightly tongue-in-cheek. The more likely case is closer to the worst case: the physical fragmentation will cause pain, the cost of the growths will cause pain and it is sort of all for not when you could have right sized the database from the beginning for a value that you can grow into over time.

Your first thought about reorganizing the database may be induced by some of the wording in SQL Server 2000 maintenance plans which sort of lump an index reorganization and shrink into what seemed like one operation (IIRC).

There are really two main kinds of fragmentation to think about here: Physical File Fragmentation (you want to prevent this by trying to minimize growths and don’t shrink your production database) and index fragmentation (which comes in two forms.. One form being your index pages no longer physically in the logical order of the doubly linked list and the other form being 8KB data pages, due to page splits from inserts/updates and due to delete activities, no longer being as full as they should be). The best way to handle this type of fragmentation is through rebuilding or reorganizing indexes, not shrinking a database.

To be honest, I can’t find any positive benefit from shrinking a production database. All that is designed to do is reduce the free space within your database files. Yes there is an option during a shrink that can reorganize data as best as possible to determine where that free space comes from but this doesn’t mean deal with index fragmentation.

I was under the impression that one of the reasons to shrink a database was to defragment the database files, something that can have a positive effect on transaction heavy databases (or so Oracle would like me to believe).You seem to be saying this is true:

Deallocate that space and let the O/S do what it needs with it. If you have a growing database (as the majority of non-static databases tend to be), this means that that database will grow again. Depending on your autogrowth settings (another pet peeve for another post) this growth will probably be more than necessary and you will end up shrinking again… At best this is just extra work (shrink grow/shrink grow) and the resulting file fragmentation is handled alright by your I/O subsystem. At worse this is causing file fragmentation, interrupting what would have otherwise been contigous files and potentially causing I/O related performacne problems."

I’m not clear what the difference is. Do you mean that the OS (or a commercial disk defragger for that matter) will handle defragmentation adequately without worrying about the internal shrink function? Another way of saying this: If file level fragmentation is an issue for an organization, simply running Windows deframentation tools will address this issue regardless of what’s done in SQL Server and you don’t need to run a separate routine for this purpose, unlike, say Oracle database?

Thanks