Sharepoint Tips and Tricks : Database Maintenance

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.

Detaching Databases in MOSS 2007 Environments.

corybu — Fri, 01 Jun 2007 17:47:00 GMT

While performing database maintenance there are few things to consider and execute to keep your environment healthy. First being preparetomove, if you are detaching databases from a production environment this is a must.

The following line is extremely important so I thought I would make it bold :)

Any database that is attached to a MOSS 2007 farm and consuming from an SSP has to have stsadm -o preparetomove executed prior to the actual detach from the farm.

This is due to several reasons, the main being IT WILL break the relationship between your shared service provider and your database. This relationship can be repaired but it essentially means losing the part of your search index that relates to that database.

The full command is below.

stsadm -o preparetomove
           {-ContentDB <DatabaseServer:DatabaseName> |
       -Site <URL>}
           [-OldContentDB <uniqueidentifier>]
           [-undo]

For detaching databases cleanly from the farm we really only care about the first 2 switches. So your command might look like this.

stsadm -o preparetomove -contentdb SQLSERVER:DBNAME -site http://www.sharepointskills.com

Followed by the following command to actually remove your database from your farm.

stsadm -o deletecontentdb -url http://www.sharepointskills.com -databaseserver SQLSERVER -databasename DBNAME

When you want to reattach your database to the farm it’s only 1 step rather than the 2 step process.

stsadm -o addcontentdb -url http://www.sharepointskills.com -databasename DBNAME -databaseserver SQLSERVER

Essentially what this does is it tells the SSP that you are relocating this database and to prepare to get a new database GUID. It tells the system that the current GUID for databaseA is stale and that when this database name is picked up the next time in the crawl to replace its GUID. With doing that is shifts all of the Site information and index's for that database to the new database GUID.

If you fail to use this command prior to the move it will create a stale entry in your SSP and all sites going forward in the database will not be crawled. Additionally it will create a pretty ugly error in your web front end application log that looks similar to the following.

Failure trying to synch web application 09a21da5-4485-4b00-8268-772aea7fea12, ContentDB 65301403-c277-4b4c-ad5a-e822572d10ea: A duplicate site ID 3b3a4372-aa91-4e0c-ba57-2567958d81bb(http://portal/sites/test1) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

This is wonderful it gives you a resolution! However there is much more to this resolution than what meets the eye.

First we need to find out which databases are currently not in sync, this can be done from a simple stsadm command on your SSP web front end.

stsadm -o sync -listolddatabases 5

This command will list all databases that have not synced up correctly with the SSP in greater than 5 days. Based on your schedule to index your age value may change. You may want to change this value to 10 or 15. The result set returned is a list of database GUID's and the date/time they were last synchronized. Now that we have determined the list we need to clean them up and get those guys synced. To do this we execute an stsadm command that sets all of those GUID's as old, then during your next index it will pick up the new GUID's for your production databases not currently being synced.

stsadm -o preparetomove -contentdb sqlserver:dbname -oldcontentdb <GUID>

where sqlserver is where your content is housed, dbname is any database in your child farm, and GUID is a guild from the list of non-syncing databases we generated with the command above.

Based on your crawl schedule wait until the next full crawl. Once it completes go back into your SSP and run the stsadm -o sync -listolddatabases 5 command again. Anything left can likely be removed at this point. You can remove what is left by running the following command.

stsadm -o sync -deleteolddatabases 5

this will delete all GUID entries in the SSP for anything that is out of sync for more than 5 days. You have now successfully cleaned all inconsistencies with syncing in your SSP. All out of sync alerts should now subside.

Remember use stsadm -o preparetomove before detaching a database and this will not be a problem!

Cory