Any reason not to create a new content database for each site collection?

Question

When creating a site collection in stsadm there are 2 commands I could use: createsite and createsiteinnewdb, where the latter creates a new content database for the site collection.

Reading around the blogs (e.g. this post), I see people saying that having each site collection in its own content database is a good idea. It can:

• stop you getting overly large DBs
• simplify backup/restore
• be good for disaster recovery.

As far as I can tell (being new to SharePoint..) it looks like a good idea. Are there any counter-arguments as to why I shouldn't create a new content database for each site collection?

Answer 1

I would like to take the opportunity to pimp a few of the posts on my own blog:

• Site Topology Planning Part 1
• Site Topology Planning Part 2

Environments can vary quite a bit in the number of site collections they will have or how deep the site hierarchies will go. The amount of content in those site collections also can very. I once had a sub-site that out of nowhere grew to 40GB which is obviously not good. It was moved to its own.

I tend to try and understand the type of site that it will be and have some expectation as to how large it will grow. I then put it in a content db based on those assumptions. If it is expected to be a site collection with many sub-sites, or if it will hold a lot of content (ECM) I will assign it its own Content DB.

In other cases there are just misc project sites or collaboration sites that stay pretty small (under 100mb). There is no value to having their own Content DB in this case, and in fact the DBA will probably hate you if you have 100 content dbs on the sql server.

Answer 2

My response echo's a little of what Mike said... a lot of site collections stay pretty small, in which case it is much more efficient to keep them in a single content database so that there's not as much overhead (more about the number of objects in the instance than a performance perspective) in SQL Server associated with them from a database perspective.

To me, this is a governance issue. I create three site collection quota templates in most environments, 1 GB, 2 GB, and 5 GB. Everything starts at 1 GB unless the site owners make a case otherwise. A bump from 1 GB to 2 GB is free, mainly its there as a checkpoint for the farm admins to ID sites that are growing quickly and as incentive to owners to clean up their sites. 2 GB to 5 GB requires approval (although who approves can vary), and at this point I want farm admins to start taking a closer look at the site, understanding what's going into it, and determining if it needs to be in its own content db or not. When the 5 GB template is used, the site should go into its own content db.

Microsoft has some specific capacity recommendations and limits tied to site collection size, content db size, and the number of content dbs attached to a given web application. These numbers vary depending on if we're talking about SharePoint 2007 or 2010, I would recommend looking at the TechNet capacity planning centers for each product for much more information on that:

• 2007: http://technet.microsoft.com/en-us/office/sharepointserver/bb736741.aspx
• 2010: http://technet.microsoft.com/en-us/sharepoint/ff601870.aspx

In general, I would rather start with three content databases with the purpose of distributing site collections across all three, and then create individual ones for site collections that I either know will be large right up front or identify themselves through the governance process outlined above.

John

Answer 3

As well as the other good information already provided by Mike and John there is also the flexibiliy you can gain from using multiple databases when you rely on the native SQL Server/SharePoint admin tools for managing your environments.

For a starter it may make your content deployment/migration and backup/restore scenarios easier (from a database perspective) especially if you do not use/have any third party products to help you.

For example: If you have a site collection in its own database, and are running multiple farms DEVELOPMENT/TEST/PRODUCTION, then it becomes quite easy to move a site collection from the production farm back to testing/development (Content refreshes etc) by using a SQL database backup/restore and then attaching the content database to SharePoint. It can also make your backup/restore more granular (from a SQL server level) as you can target specific site collections by just backing restoring those content databases.

With that in mind your maintenance headache becomes bigger when you’re dealing with many content databases instead of just one. Make sure you use good naming conventions e.g. WSS_Content_SiteNameOrPurpose_DEV or your DBA/Administrators will really start to hate you :)

Answer 4

It increases the amount of administration, having to take backup of 10 databases instead of 1.

It may place a greater load on the database server.