Answered by:
Old DB Size did not reduce after using Move-SPSite http://sharepoint/sites/moveme -DestinationDatabase WSS_Content2

Question
-
I have a Content DB "ContentDB1" with a size of 250 GB. In that, i am having two site collections each consuming more than 45 GB of the content DB. i want to move the two heavily used Site Collections to a new Content DB namely ContentDB2.
Yesterday i used the Move-SPSite http://sharepoint/sites/moveme -DestinationDatabase ContentDB2 to migrate my two site collections to the new content DB contentDB2.soon after migration the DB size of my Content DB cintentDB1 was 250GB and the size of ContentDB2 was 93GB. But even after 24 hours of the migration the DB size of my Content DB cintentDB1 is still 250GB and the size of ContentDB2 is 93GB. I want to reduce the Size of my ContentDB1. i thought the size will automatically get reduced after migration ,but that did not happen. can anyone tell me how to remove the unwanted two site collection data from my contentDB1 and reduce the size of my DB.Please help me.
Tuesday, November 5, 2013 6:39 AM
Answers
-
For the first time since i've been posting on Technet the correct answer is to shrink the database.
By default Databases are assumed to grow not shrink. There is no automated (nor should there be) process to reduce databases when space is freed up.
This shows you how to Shrink the DB: http://technet.microsoft.com/en-us/library/ms190488.aspx
Once it's shrunk as soon as it's used again it will expand a bit. It might start at 250GB, go to 150GB as you shrink it and then shortly bounce back up to 200GB. That's normal as the Shrink command reduces the size below normal working levels.
- Proposed as answer by Matthew Yarlett Tuesday, November 5, 2013 10:34 AM
- Marked as answer by Pratik Vyas Saturday, November 16, 2013 1:04 AM
Tuesday, November 5, 2013 9:42 AM
All replies
-
For the first time since i've been posting on Technet the correct answer is to shrink the database.
By default Databases are assumed to grow not shrink. There is no automated (nor should there be) process to reduce databases when space is freed up.
This shows you how to Shrink the DB: http://technet.microsoft.com/en-us/library/ms190488.aspx
Once it's shrunk as soon as it's used again it will expand a bit. It might start at 250GB, go to 150GB as you shrink it and then shortly bounce back up to 200GB. That's normal as the Shrink command reduces the size below normal working levels.
- Proposed as answer by Matthew Yarlett Tuesday, November 5, 2013 10:34 AM
- Marked as answer by Pratik Vyas Saturday, November 16, 2013 1:04 AM
Tuesday, November 5, 2013 9:42 AM -
Isn't there any other way? bcoz according to my Google Search results, DB Shrink is a risky process. Why isn't the Gradual Site Delete Timer Job Doing its work Properly?Wednesday, November 6, 2013 7:13 AM
-
You are right .
The DB shrink Process is not recommended by DB administrator specially in SharePoint and this will put your content database in performance issue and also risky process.
the solution for this is after free some sites and documents from your site collection and also from end recycle bin stage is to create new free database then use this command sp-move to move the site collection to the new database created .
Also you can planned to use wildcard path to create multiple site collection every one in each own database this will simplify the data growth
at the end it is all related to your design and your data growth business needs.
- Edited by sword22222 Monday, January 20, 2014 1:00 PM
Monday, January 20, 2014 12:59 PM -
Not really no. If you move sites out of the content database it will not reduce in size. If you can leave the space there then do that, in time your database will grow to use that free space.
On the other hand if you need the space freed up, or it's so large an amount of space that you won't really make use of it, then your only choice is to shrink the DB.
Now, as i allude at the start of my post shrinkDB isn't a step you want to do lightly or often but it does have some uses and this is one of them. The performance issue that sword mentions is real but will pass in time.
The gradual site delete timer job might remove content from the database but it won't reduce the file size on disk. That isn't the role of the timer job as SharePoint doesn't want to, or try to, reduce database file sizes itself. The files could be hundreds of Gigabytes but only hold a few megabytes of data.
Monday, January 20, 2014 1:13 PM -
Yes and no.
ShrinkDB is a bad idea under most circumstances but if you need to release free space in a content database it's the only way to do so. None of the steps you list will reduce the size of mdf or ldf files.
Monday, January 20, 2014 1:15 PM -
For the first time since i've been posting on Technet the correct answer is to shrink the database.
It was bound to happen eventually!
Monday, January 20, 2014 3:11 PM -
i'm afraid that maybe it wasn't the right answer since shrinking the database did very little for me.. I have a 263 GB content database which I have moved over 100 GB of site collections out of. I ran the gradual delete timer job and also shrank the database and its still 255 GB in size. I'm trying to move the last site collection out of this content database (its 147 GB) and then I could delete this bigger content db, but powershell keeps returning
"The instance of the SQL Server Database Engine cannot obtain a LOCK resource at this time.
The whole point of moving site collections for me was to free up space and reduce content database size. Its pretty lame that this doesn't happen!
krd
Friday, August 26, 2016 4:04 PM -
Interesting. Can you check how much free space you have in the SQL DB? This should do the trick: http://dba.stackexchange.com/questions/7917/how-to-determine-used-free-space-within-sql-database-files
If there's no free space then there won't be any reduction by shrinking.
Friday, August 26, 2016 5:18 PM -
funny I checked it this morning and suddenly I have a lot of free space available (80 gb) .. it must have been something that happened over night (a timer job?) because I didn't have more than 5GB of free space yesterday. I'm going to wait until tonight (when our office is closed) and run the shrink command.. i'll report back on Monday
krd
Friday, August 26, 2016 5:48 PM