Question

I had a table with 70+ million records in a SQL Server database, I dropped that table (a one-time thing) to free up space on the disk, but it looks like the size didn't change much. I do see that I could shrink the db to a minimum.

Is that the way to do it?

The last time I did a shrink using SQL Server Management Studio, it took a few hours to complete. Is there a faster way?

enter image description here

Was it helpful?

Solution

Dropping a table will free up the space within the database, but will not release the space back to Windows. That requires shrinking the database file. However we don't want the database file full. We want lots of free space so that as we load more data we don't have to grow the data file frequently. This causes fragmentation of the data file on the physical disks.

As for making shrinking faster, no there's no way to make it faster. Shrinking the database requires reading and rewriting most of the data within the database so that all the white space can be released from the database file back to the OS. All this IO takes time, and causes a lot of fragmentation problems.

OTHER TIPS

You'll want to read about DBCC SHRINKFILE very carefully.

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

In general, you don't want to shrink your database to the smallest possible size on disk. You want to leave SQL Server with plenty of space so that it doesn't have to auto grow much. The answer here has a lot of useful info:

https://stackoverflow.com/questions/4522719/to-dbcc-shrinkdatabase-or-not-to-dbcc-shrinkdatabase-thats-the-question

Shrink is quite expensive procedure and might take hours. To use space most efficiently you may transfer tables into new filegroup with clustered indexes precreated and drop previous. I personally prefer this because it's easier to make this "shrink" in several steps and more predictable- thus easier to plan. When you start DBCC SHRINK you don't know how much time it will take.

Update (Thanks to mrdennny for pointing that): this is a very specific approach and can only be used if you have a read-only database (like data warehouse) because while copying data to another table no writes are allowed to this table for the sake of consistency. To save time and gain max performance of it you may switch database to SIMPLE recovery model and use TABLOCK hint - this will allow system to use minimal logging and do much less writings into transaction log.

Check out this article: http://itknowledgeexchange.techtarget.com/sql-server/deleting-lob-data-and-shrinking-the-database/

"The solution that we came up with was actually pretty simple. Do the database deletion as normal. Then backup and restore the database. Then do the shrink, followed by rebuilding the clustered indexes in order to fix the fragmentation issue which the shrink will introduce."

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top