SharePoint Site Moves, Database Moves and Balancing Growth

corybu — Thu, 21 Jun 2007 10:30:00 GMT

SharePoint adoption is at an all time high right now with the release of MOSS 2007 and WSS 3.0, this is wonderful for your investment but can be a nightmare for a poorly planned deployment that was not ready for massive growth. Certain operational tasks may be on the horizon to better balance your content databases in regard to site size, database size and potentially even your SQL storage plan in general.

Site Moves are an important part of maintaining your SharePoint environment. Situations may arise where a site has outgrown other sites by a substantial amount. To help support this larger site in an intelligent manner we need to migrate it to its own database away from other site collections (Split). Additionally if you know that a site has the potential to grow substantially this would be a good idea as a proactive approach. We will refer to this action as splitting a site. Other situations can also warrant splitting sites out of a database such as your site max cap was set to high initially and now you have too many site collections in each database or for legal or business reasons you need to separate certain sites from other sites even at a database level.

Balancing Databases would be another action you may need to entertain to help gain control over your growth. This may be as simple as detaching a database from SQL and moving it to another LUN on your SQL instance or migration of the database to an entirely different SQL server, or as complex as load balancing your site creation between LUNS / SQL Servers.

Site Moves

To migrate a site collection from 1 database to another with control first we need to understand how SharePoint decides where a new site collection is created. SharePoint will place a new sitecollection into the content database with the largest delta between sitecount and sitemax. What does that mean exactly, lets look deeper.

As you can see above the delta for demo_content_1 is 500 – 3 (497) and the delta for demo_content_2 is 500. The larger the delta is determines where your site goes. The next site created will go into demo_content_2.

With that being said you now have the ability to migrate sites to the database of your choice. To perform this move you would simply do the following 3 commands.

stsadm -o backup -url http://demo/sites/test2 -filename e:\test2.bak

stsadm -o deletesite -url http://demo/sites/test2

stsadm -o restore -url http://demo/sites/test2 -filename e:\test2.bak

If we refresh the content database page we can see that our site has moved to demo_content_2.

Database Stripping

In the event that your site has grown beyond the limitations of stsadm (in our testing no more then 15GB) you may need to entertain the path of database stripping. For database stripping we would take a backup of the database that contains the larger site and attach it to a testing / restore environment. You would then use stsadm to delete all site collections except the larger site. This in effect has singled out your site collection into its own database. Then when you reattach that database to your production farm which contains this 1 site you want to set your site warning limit to 0 and site max to 1, thus to keep that 1 site separate into its own database.

Balancing Databases

To help increase performance and manageability you may want to at some point balance your content databases across multiple LUNS or even SQL servers. In the event you want to migrate your database to another LUN on the same SQL server instance I recommend the following steps.

- Inter SQL Server Database Move

First leave your database attached to your farm, there is no reason to detach your database from your SharePoint farm if your moving it inter SQL Server. Simple Detach the database from SQL and copy your .MDF and LDF to the share of your choice. Then reattach your database in SQL and perform an IIS reset on your SharePoint Front end. Also leaving your SharePoint Content database attached helps avoid orphan site collection creation.

- External SQL Server Database Move

Log Shipping Method(low impact)

To migrate your content database from 1 SQL Server to another there are a few choices, your choice will depend on how much downtime you are willing to take. First option being you can setup SQL Log shipping, Once your 2 databases are in sync you would do the following steps.

Stsadm –o preparetomove –contentdb SQLServerA:demo_content_1

Stsadm –o deletecontentdb –url http://demo –databasename demo_content_1 –databaseserver SQLServerA

At this point you would perform the final cutover on your log shipped database to SQLServerB

Then finish with

Stsadm –o addcontentdb –url http://demo –databasename demo_content_1 –databaseserver SQLServerB

Copy Method(high impact)

Your other option would be to simply detach the database from SQL and copy the .mdf and .ldf to the new SQL server. While in transit your users will get a generic “Cannot connect to content database” error when visiting their site. Following the copy you would perform the following on your web front end.

Stsadm –o preparetomove –contentdb SQLServerA:demo_content_1

Stsadm –o deletecontentdb –url http://demo –databasename demo_content_1 –databaseserver SQLServerA

Stsadm –o addcontentdb –url http://demo –databasename demo_content_1 –databaseserver SQLServerB

Load Balancing Site Creation

Using the methods explained above we can in a sense load balance our site creation between content databases and SQL Servers. We can do this by creating multiple content databases across SQL LUNS and SQL Server instances.

Since site creation is based on delta it will create the next new site collection in demo_content_3 or demo_content_4. Once both of those databases reach a site count of 1 it will repeat the process against all 4 and so on. You will then always have +1 -1 Number of site collections between your content databases.

Sharepoint Tips and Tricks : Migration

SharePoint Site Moves, Database Moves and Balancing Growth