Splitting large size content database

Question

One site collection has large size content database

Want to split large size content database into smaller pieces to make each lower than 80 GB. I saw on reply which seems to be realistic. any other better suggestion to perform the same thing?

Let's say content db is 700GB in size & we need to split it. what should be strategy?

---

Another user's reply:

You can create a new blank content database in a NEW web application. After that, you can do backup-spsite from the current content db, make it read only in the current web application, restore it in the new content database. After that make sure it's not Read locked from CA and once you verify that everything has been restored in the new content database, you can delete that site collection from its old web application. Make sure that the managed path exists in the target web application. Repeat this process for all the site collections you want.

Answer 1

You shouldn't need to go through the trouble to back up and restore the site collection. There is a Powershell function called 'Move-SPSite' which will do that as well. It will also automatically writelock the site collection in question while it's moving it.

The biggest issue with this is that the Powershell functions start to fail when your site collections get extra-large (I think ~75GB is the absolute upper limit but because you need IIRC 2-3 times the memory available for the site in your RAM and pagefile, more than ~20GB is a more practical limit). The only way I know of to get around that is to split off some of the subwebs in a given site collection into their own site collections, which requires you to do the following:

1. Run Export-SPWeb on the subsite in question and save the .cmp files somewhere.
2. Create a brand new site collection named whatever you want.
3. If the site collection in question has an esoteric web template (like an Access Services template) you may need to create a leaf that utilizes that as well, as Export-SPWeb will not export to a different template.
4. Run Import-SPWeb on the subsite and bring it into the site collection.
5. Perform the Move-SPSite as you would have before.
6. Once you're 100% positive everything is running correctly, delete the subsite from the original (since the whole point of this exercise is to lower the size of the site collection).

The downside to this is that URLs are going to change. You can always put them back when you're done, but you want to make 100% sure that you have everything you need in that exported SPWeb object because there's no going back (save pulling old DBs from your archive, assuming you have SQL backups).

ETA: To your follow-up comment: If they're still a lot of separate site collections, you can still run the backup/restore deal I mentioned above. One thing you might want to do beforehand is run this command:

http://technet.microsoft.com/en-us/library/cc262492(v=office.12).aspx

stsadm -o enumsites -url http://yourwebapp.com >> d:\siteinfo.xml

This should pop out an XML file which will contain a lot of data about each site collection: its size, site collection owners, and so on. You can then open that file in, say, Excel, and devise a plan to move those collections out to their own content DBs. Keeping the new content DBs below 100GB and maybe ideally around 75GB is a good rule of thumb.

This whole process can take some time to do as well so you may need to deploy it in stages.

Answer 2

It is not about splitting the Content DB but splitting the content inside them. Imagine if you have a huge video portal, you can split the videos into site collections by a category so the content DB size will get lower.

There are PowerShell scripts to manage the moving and etc with the content DBs as NotVonKaiser has mentioned. But better if you could rethink of the strategy.

Answer 3

Just an idea. You could export the huge content sites over to a new Site Collection with it's own dedicated content database.