November 28, 2013 at 1:47 pm
SQL Server 2008 R2
The drive with our main database file is almost out of disk space. We are getting new drives prepared but in the mean time I have a couple questions. I want to avoid a database shrink unless it is an absolute emergency. I've deleted hundreds of thousands of old unneeded records and this is increased the unallocated database space by quite a bit but it has of course not increased any free hard drive space.
Even with the unallocated space the free hard drive space is daily shrinking lower and lower. I had hoped SQL Server would use only unallocated space first before using any more new disk space but apparently it is not. So, will my database crash if the drive space runs out or will it use up the unallocated space at that point? Also, at what point should I bite the bullet and run the database shrink?
November 28, 2013 at 9:55 pm
Hi,
dropping objects or deleting rows will not reclaim occupied space unless you explicitly run commands to reclaim space.
when your file group is full and no more able to allocate additional space through auto growth or through manual process it stats throwing you error and will not make use of unused free space.
one solution may be to set a small autogrowth for the datafiles may be 1MB, that will not cause the disk to run out of space in single growth.
last solution would be to shrink you data files to release space to OS, but shrink operation creates massive index fragmentation.
November 28, 2013 at 10:30 pm
ryan.costello (11/28/2013)
I've deleted hundreds of thousands of old unneeded records and this is increased the unallocated database space by quite a bit but it has of course not increased any free hard drive space.
No, that will only increase the free space in the file
I had hoped SQL Server would use only unallocated space first before using any more new disk space but apparently it is not.
It will do that. It could be that the free space you created is free space on allocated pages, not empty, unallocated pages. SQL can't use free space on a page belonging to tableX for tableY. You probably need to rebuild indexes to see that free space made available to the rest of the DB.
Don't shrink, you want free space in your database to let SQL reuse that free space. That's not what shrink does.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply