One widely held misconception about SharePoint 2007 is that a Web Application can only span a single Content Database.  The truth is that a Web Application can span multiple Content Databases, the limitation is at the Site Collection level.  Why this is an important concept is because of the fact that a single Content Database for a SharePoint Solution is not ideal, as the size can get very large quickly, and there is no easy way to move content out of a Content Database.

The solution to this issue is to create multiple Site Collections within a Web Application and to add those Site Collections to their own Content Database.  A scenario for this would be as follows: Let’s say that CompanyABC wants to setup an enterprise document management platform using SharePoint 2007.  They configure the namespace docs.companyabc.com as a Web Application on SharePoint, then they configure a root site of http://docs.companyabc.com with a single Site Collection and single Content Database.

Since CompanyABC realizes that the amount of content in the system will grow large very quickly, when the create the platform they configure the documents to be stored across multiple site collections by department.  They create a Managed Path in SharePoint of /dept/ and then create site collections under the Managed Path, configuring those Site Collections to have their own Content Databases.  So, http://docs.companyabc.com/dept/it has its own content database, http://docs.companyabc.com/dept/hr has its own, http://docs.companyabc.com/dept/marketing does as well, and so on.

The reason for all of the confusion about being able to do this stems from the fact that the Site Collection creating GUI in the SharePoint Central Admin tool does not prompt the administrator for which Content Database to add the Site Collection to.  To make matters worse, SharePoint simply chooses which content database to add to by doing a ‘smart’ analysis of current database usage, which doesn’t allow for any control over where the Site Collection goes.

There are two methods of getting around this.  In the first method, the administrator goes to all Content Databases (SharePoint Central Admin – Application Management Tab – Content Databases) and takes the databases ‘offline’.  Note that simply taking the databases offline does not affect user functionality; it only dissallows new Sites from being created in the specific Content Database.  Once all Content Databases except for the one desired are taken offline, creating a new Site Collection will force that Site Collection to be created in the one you want.

If the databases aren’t created in advance, there is an even easier way to do this, by using the –createsiteinnewdb flag with the STSADM tool.  The STSADM tool (located on web front-ends in the \program files\common files\microsoft shared\web server extensions\12\bin folder) is a fantastic administrative tool that performs a myriad of administration with SharePoint.  In this case, it allows you to create a new Site Collection within a new Content Database.  The following Syntax illustrates one example:

stsadm -o createsiteinnewdb -url http://docs.companyabc.com/dept/hr -owneremail -ownerlogin COMPANYABC\SPAdmin -sitetemplate sts -title “Human Resources” -databaseserver SERVER1 -databasename HR-Content-DB

In this example, a new site collection is created at the URL http://docs.companyabc.com/dept/hr.  The Site Collection Owner is set to COMPANYABC\Spadmin and the Site Collection owner email is set to .  The default team site template is used to create the site (the template is simply named ‘sts’, without the quotes.)  The database server is SERVER1 and the name of the database created is HR-Content-DB.

Using this concept, you can construct a SharePoint environment that will scale quite nicely, as content is distributed across multiple databases.  In addition, If you need to scale to multiple database servers, it simply involves moving content databases to the new server and updating the location in SharePoint.

Cheers,

Michael