Claim SQL server space after content deleted from SharePoint

Question

We have a site collection with its own database where we have been testing migration of a department's shared drive content (about 40GB) via a third party tool. The test migrations went fine. Before running the final migration, we deleted the test content off of the site collection. Now the SharePoint storman page reports the correct size of the final migration (40GB) but SQL server is reporting a size that is double the correct size. From the research I have done SQL server will not let go of space that once had content allocated.

How can we reclaim those space by not affecting SharePoint?

Answer 1

I have never done it personally but Microsoft has a document that lays out the steps pretty clearly. As always, be sure to take a good backup before attempting this.

Shrinking a database by using SQL Server 2008 Management Studio

1. On the taskbar, click Start, point to All Programs, point to Microsoft SQL Server 2008, and then click SQL Server Management Studio.

2. In Object Explorer, connect to an instance of the SQL Server 2005 Database Engine and then expand that instance.

3. Expand Databases, right-click the database that you want to shrink, point to Tasks, point to Shrink, and then click Files.
4. Select the file type and file name.
5. Optionally, select Release unused space. Selecting this option causes any unused space in the file to be released to the operating system and shrinks the file to the last allocated extent. This reduces the file size without moving any data.
6. Optionally, select Reorganize files before releasing unused space. If you select this option, you must also set the Shrink file to value. Selecting this option causes any unused space in the file to be released to the operating system and tries to relocate rows to unallocated pages.
7. Optionally, select Empty file by migrating the data to other files in the same filegroup. Selecting this option moves all data from the specified file to other files in the filegroup. The empty file can then be deleted. This option is the same as executing DBCC SHRINKFILE with the EMPTYFILE option.
8. Click OK.

Answer 2

I was asked to reduce a content DB recently, heres what I found. Whilst the customer was great in deleting content from their sites, SharePoint has a 2 stage recycle bin, so whilst the items were deleted from the site level recycle bin there was still 30 days left on the site collection recycle bin. So please ensure you check that and flush it.

Yes you'll find that the DB will still be large at this stage. So as described above, use SQL Management studio and locate your content database in question, it won't be the SharePoint configuration database as the example shows above but rather WSS_Content_something in all likelihood.

After that you find you will be able to shrink the database file (mdf). BUT! beware chances are your database is set to full recovery mode and when the shrink operation takes place all it will do is blow the transaction log out as many GB as you have removed. So the choice here is you might want to switch the DB into simple mode and then perform the shrink operation> I was lucky in that I had sufficient disk space when the shrink operation was taking place and removing 40GB blew the logs out 40GB, once that was complete the mdf was then shrunk 40GB. After this I switched the DB to simple mode and shrank the log file, then changed it back to full.

Answer 3

So if you deleted your content (also from SharePoint Recycle Bin) next step is to shrink Sharepoint database to claim back your space.

Here is simpele tutorial (with pictures): How to shrink SQL / SharePoint database / log files

I belive only first 5 steps are needed:

1. If you don’t have it yet, download and install SQL Server Management Studio express from here.
2. Run the Management Studio and connect to your SQL Server.
3. Expand “Databases” and select your config database “SharePoint_Config”.
4. Right Click it, select Tasks –> Shrink –> Files
5. In the new window select Release unused space and click OK.

Answer 4

I'm gonna throw this in because it needs to be added. It's not an 'answer' but it's related to the others here as a supplement, and it's an absolute golden Best Practice that absolutely should be performed on every single SharePoint Content Database that you manage.

Once you release the free space from a truncated LDF after a Simple Mode backup to do whatever movement of the files that you need to - PREGROW ALL FILES BACK TO WHAT THEY WERE, OR WHAT YOU CAN AFFORD TO DO SO.

When SharePoint content gets added or delete, or even updated, SQL Server will populate the MDF and LDF files (the ratio of which depends on your recovery model set on that particular database). SharePoint does this a lot, especially with busy sites.

When you start using a SharePoint site straight after releasing the freespace, the LDF/MDF files for the database start to get written to. Because they're technically maxed out (because you shrunk them), SQL will grow the files automatically depending on some setting (usually increase by 10% or, at it's worst configuration: 10MB).

This growing has a performance penalty. A pretty noticeable one too.

So, if you shrink your files, the database will claim back that space over time anyway, and it WILL slow down the site for your users as it does this. Give them that little bit of experience bonus and save SQL from autogrowing.