SharePoint Dragons

In his first job, Nikander started out as a junior internet engineer for the newly founded Internet division of a large Dutch media company (Wegener). The internet division was called WIN (Wegener Internet Nederland) but didn’t exist long (only 2-3 months) because Wegener decided to buy one of the most successful Dutch internet companies of the time: Riverland (later this company was called Netcast, but it also doesn’t exist anymore).

Because of this lucrative take over, the ceo’s of Riverland decided it would be a good idea to move to a different location and expand. The ceo’s even had a better idea: they understood that they could save some money by letting all junior developers move the stuff and let them do the cabling for the building, instead of hiring professionals to do the job. During this period of a couple of weeks, Nikander only saw computers from a distance, but did get his hands on miles of cables and hundreds of cable ties. We stumbled upon this web site, so for old time sake, if you want to be like Nikander and have fun with cable ties, please check out cable ties and hundreds of cable ties.

Once Nikander was allowed access to computers again, one of the first problems he was dealing with was a database not performing well because of its size. Recently, a customer experienced the same thing. They have a single SharePoint content database, used by a single site collection containing many subsites, which is gaining rapidly in size, already surpassing 200 GB. How to deal with this?

First some pieces of relevant knowledge:

• A site collection can be moved to another content database.
• A single site collection is connected to a single content database.
• You can set the content database status to offline to prevent new site collections being connected to such a content database.
• Offline content databases will still continue to grow in size because of new content in existing site collections.
• Don’t let the content database stay in offline status for too long (see http://www.sharepointsteve.com/2011/02/side-effect-of-setting-content-databases-to-offline for more info).
• You can have +/- 300 content databases per SharePoint web application.
• You can have +/- 2000 site collections per content database, and 250,000 (non personal) site collections in a farm.
• The recommended maximum site collection size is 100 GB.
• The recommended maximum content database size is 200 GB.

BTW, if you like some help with checking SharePoint requirements, try the SharePoint Max Dragon (http://gallery.technet.microsoft.com/Maxer-for-SharePoint-2010-8cd0f26f).

In this scenario, the approach of dealing with a large content database goes something like this:

• Create new content databases.
• Put the current one in offline status.
• Promote current sites to site collections via custom code.
• Divide site content equally among new content databases to share the load and adhere to MS size recommendations.
• Change old content database status back to normal.

As a rule of thumb, we like to go for content databases of approx. 50 GB in size.

Now, we know not everybody has the possibility to use custom code, and most of the time it’s not even the best approach. Instead, you can use one of the quality sharepoint migration tools out there.