Get MS SQL Server to release disk space

Question

A poorly managed database table has grown to be enormous. 48+gigs of orphan records. I am trying to clean it up and put my dangerously full hard drive back to a normal state. I will be deleting approx 400 million records from this table. This is running as I type. I notice that I am not seeing any drop in my hard drive space but I am seeing the memory drop on system table queries, I am running to get table size. The database is using "Simple Recovery Model".

There are many questions similar to this with responses saying you need to shrink the database. But they go on to explain how bad/scary this is to do because of fragmented data etc.

1. Since the database should not be this size. Is it still bad for me to shrink it?
2. This is a production database. If I shrink it will it cause downtime or lock the database?
3. In SQL Server Management Studio you have two options for shrink, database or files. Given my situation what would be the best option?
4. is there a rule on the percentage of free space a DB should have?

Even reading the tag description of shrink makes me not want to do it. Is there another way?

Answer 1

I will be deleting approx 400 million records from this table.

Hopefully, you are doing it in chunks - to avoid bloating transaction log.

notice that i am not see any drop in my hard drive space

You wont, as you have to explicitly shrink the database file to release space. Just deleting the records, SQL server wont release the space back to the OS.

1. Since the database should not be this size. Is it still bad for me to shrink it?

It is generally a bad practice as databases should be presized properly. If you are 100% sure that your database is NOT going to be again this size, its OK for you to shrink the database (in your scenario).

2. This is a production Database. If I shrink it will it cause downtime or lock the database?

Shrinking a database is a very IO intensive. Its advisable to shrink using DBCC SHRINKFILE during maintenance window or when there is minimal activity.

3. In management studio you have two options, Database or Files. Given my situation what would be the best option?

You should use TSQL to do the shrink. (since you asked, shrinking FILE is the way to go instead of database). You can use shrink database in chunks - tsql script to do the shrink in chunks.

Remember that when you shrink, you are fragmenting your indexes.

4. is there a rule on the percentage of free space a DB should have?

You can refer to Estimating Disk Space Requirements for Databases article. There is no fix rule, you have to take into account of how your database is expected to grow. You also have to take into account, autogrowth of your databases.

References : Why Does the Transaction Log Keep Growing or Run Out of Space?

Answer 2

you have good reason to be concerned as DB shrinks in SQL Server often "suck". Paul Randal, the head of the Storage Engine in SQL 2005 stated, ShrinkDB is written very poorly. It will find empty space by taking the data at the very end and put it in the very beginning and keep doing this until it has free space at the 'end' of the DB files. At this point it can then release the space from SQL Server and give it back to the OS. You are effectively reversing your database files thus you will see massive fragmentation usually. You can read about his views on this blog post or on this MCM Internals Video

As with everything, you really must test these in your environment first. A better way of doing it is to move data to a different filegroup. You can do a online index rebuild with the clustered index and then reindex in the new filegroup. Then you can drop the old one and release the space and have almost no fragmentation. Note this will take about 120% extra space while it's working through it. The problem with this is that you need even additional free space which it looks like you might not have. This is an enterprise feature.

If free space is at that much of a premium, then you might have to bite the bullet and slowly shrink the DB a small chunk at a time to avoid long running processes. Note that your data will be heavily fragmented and you will want to reindex everything again. Note that after reindexing everything, you will then balloon up your used space a bit and go back to having additional free space. See Brent's advice here.

As far as how much free space is good for you, is a matter of how much you can afford fragmentation and file growth activities. With IFI enabled, the file growth is almost instant but you still get fragmentation. A good rule of thumb is to preallocate as much as space as you think you'll need, or monitor the growth and adjust in chunks periodically if you have to. This keeps physical fragmentation down.

Also log file growth is a lot more important. Additional log files can cause VLF fragmentation. This makes your restores a lot slower and can affect checkpoint/truncates. Here's some performance risks you take with a fragmented log. Do a DBCC LOGINFO(); on each database. Try to keep the number around 50ish per Kim Tripp, but if you see hundreds, you have fragmentation issues which means your log files had to grow to support operations. A good way to see what your log file should be per Paul Randal is to just let it grow for a week and reindex. That could be a good point, perhaps you can throw a bit more free space on there just in case. Make sure your logs are not fragmented with DBCC LOGINFO(); again and if they are, it means they grew a lot. Shrink and re-expand the log file using this method.

Answer 3

It's ok for you to shrink it enough to ensure your server won't crash in the amount of time it takes you to assess your storage needs and plan hardware / hosting services appropriately (see question 4). No it won't lock it. See restrictions. Shrink the database because it keeps things simple.

I suggest contracting the expertise to conduct the study and write up the plan.