This next “Best Practice” proposal involves what I’m calling “Locking down the Portal Database”.

All this means is that immediately after creating a new Portal we restrict the content database so that it can store only Portal content. We do this using standard SharePoint functionality, specifically, the ability to restrict the number of “sites” (the UI calls them “Sites”, but they are actually “Site Collections”) stored in an individual content database.

The first question this raises is what exactly constitutes a “site collection”, well, here is a summary:
1. A Portal is considered a single site collection
2. A “My Site” is considered a single site collection
3. A “Team Site”, when created using Self Service Site Creation (which is what is used when selecting “Create Site” from the Portal), is a considered a single site collection.

Why do I consider this a “Best Practice”?
The main reason for “Locking down the Portal Database” is that since a Portal is considered a single site collection its content cannot be partitioned across multiple databases. To put it in another way, the information in a single portal MUST be stored in a single database. Given how important a portal is to your intranet it is likely to grow quite large, therefore, by ensuring a dedicated database you ensure it’s as small as possible, which in turn makes it as manageable as possible, particularly from a backup/restore perspective.

After locking down your portal database, you then need to create additional databases for storing “My Sites”. An important thing to consider here is that the division of portal data versus “My Site” data is not quite as simple as it could be. This goes back to the architecture of “My Sites”, rather than being entirely self contained, the home page of a “My Site” is actually nothing more than a specialised Portal Area. Therefore some “My Site” content, mostly the web parts and layout, are actually stored in the Portal site and therefore the Portal content database. For more information review my previous post here.

In my previous best practice post we created a dedicated Windows SharePoint Services farm, this means we had already created dedicated databases for Team Sites. Upon completing this configuration we will actually have a database design that looks something like this:

  • Portal_SITE
  • Portal_CONF_db
  • Portal_SERV
  • Portal_PROF
  • Portal_MySite(1…..X)
  • WSS_SITE(1…..X)

A final point. The first time I looked at this I thought it also offered some additional disaster recovery options, believing I could restore just the portal database, or just a “My Site” database in the event of disaster. However this is not the case, from a Portal perspective all databases have to be backed up, and restored, as a unit to ensure supportability. The same doesn’t apply to Windows SharePoint Services, which does allow for a single database to be restored independently of the other WSS databases. 

The following steps should be performed immediately after creating your first Portal.

Locking Down the Portal Database
Once the portal database is locked down, an additional database needs to be created to enable the creation of user My Sites.
a. Open SharePoint Central Administration - Start -> Administrative Tools -> SharePoint Central Administration
b. Click on the “Configure Virtual Server Settings” link
c. Click on the “Portal” link
d. Click on “Manage content databases”
e. Click on the database name
f. On the “Manage Content Database Settings” page, change the “Maximum number of sites that can be created in this database” to 0, and change “Number of sites before a warning event is generated:” to 0, thus preventing any more sites, like “My Sites” being created in the database.
g. On the “Manage Content Databases” page click on “Add a content database” to a database for “My Site” content.
h. On the “Add Content Database” page, stay with defaults, adding a warning at 10000 and maximum at 15000
i. Select the option “Specify database server settings” and then enter a database name of “Portal_MySite1”, and click “OK”