Skip to main content
Trans Am

Todd Klindt's SharePoint Admin Blog

Go Search
Home
Blog
Netcast homepage
SharePoint Terminology Wiki
  

Todd Klindt's home page > Todd Klindt's SharePoint Admin Blog > Posts > Move Site Collections in a Single Bound
Move Site Collections in a Single Bound

edit: Please read this blog post before using 'mergecontentdb' data corruption may occur

On multiple occasions as a SharePoint administrator I have needed to move a Site Collection from one Content Database to another one. In the past this process was very painful and very manual. In this blog post I will show you how to move Site Collections between Content Databases with a single STSADM command using the "mergedbs" operation that was introduced in KB934525.

Why would I need to move a Site Collection to a different Content DB? This comes up for a variety of reasons. For instance, because of restore times, I like to keep my databases under a certain size. While I try to work with my Site Collections owners to plan accordingly sometimes they grow larger than we had imagined. When this happens I need to shuffle Site Collections around to keep my databases in harmony. There are other times when I would do it if it were more convenient. If Site Collections are not growing as expected, I may want to consolidate several into a smaller Content DB. I may also want to move less active Site Collections to Content DBs on slower discs, or move Site Collections to Content DBs that reflect geographic regions. Whatever the reason, in the past to move a Site Collection you had to go through the following steps manually;

  1. Lock the Site Collection
  2. Back the Site Collection up
  3. Delete the Site Collection
  4. Set all your Content Databases' maximum allowed sites to the number of current sites.
  5. Set the Content Database you want the Site Collection to go into to allow one more Site Collection.
  6. Restore the Site Collection
  7. Unlock the Site Collection
  8. Adjust your Content Database maximums to allow new sites to be created.

All of these steps could be done with STSADM so you could build scripts and move through the process quickly. In one of the recent security patches (KB934525) for WSS and MOSS Microsoft slipped in a new STSADM operation, mergecontentdbs. I assume this operation was added with the intention of merging Content DBs, but it can also be used to split them. This blog post will walk you through both uses. Let's start with the configuration below:

You can see in this screenshot that I have three Site Collections in two Content DBs; WSSContent and WSSContent2. Let's move http://barcelona/sites/stsadm from WSS_Content to WSS_Content2. If you get the help for the mergecontentdbs operation it looks like this:

We want to use operation 3, Read from file. STSADM has given us a clue about the file needed, it is generated from stsadm –o enumsites. I'll go ahead and run that and pipe it to a file like this:

This will produce a file, mysites.xml, that contains my site collections. To move http://barcelona/sites/stsadm we'll remove all of the other Site Collections except for that one from mysites.xml and save it. You don't need to worry about changing the Site Count at the top, or any of the other Site Collection information in the file, STSADM only grabs the URLs out. I only have two Content Databases so the decision of which database to move the Site Collection to is easy. What if I had many Content Databases? You can use the first operation, Analyze, to get an idea of how your Content Databases are laid out. Let's see how that looks:

You can see here where I got the idea to use the filename mysites.xml. The thing I love best about this screen is that you can just cut and paste the final command into your Command Prompt if you'd like. I think Microsoft did a great job with the usage on this command. One thing to note is that the –url parameter is NOT the URL of the Site Collection you want to move, it's the URL of the Web Application that the Site Collection is in. Since we've already created our file and edited it, let's go ahead and run the command.

That's all there is to it. After an iisreset we see that the Site Collection http://barcelona/sites/stsadm is now in WSS_Content2. You can confirm it by looking in Central Administration > Applications > Content Databases before and after you run the command.

I have one final thing to show you, what I imagine is the intended usage of mergecontentdbs, merging two Content Databases. If we use the second operation STSADM will simply move all the Site Collections from the Source database to the Destination database. Let's move all of the sites in WSS_Content2 back into WSS_Content.

I think that picture pretty well sums it all up. Now all the Site Collections in the http://barcelona Web Application are in WSS_Content, right where we want them. I think Microsoft did a pretty good job with this addition to STSADM. Enjoy it.

I'd like to give a special shout out to Joel Oleson for telling me to look for this little gem.

tk

Comments

Nice Article

I have a small Inquiry , if i have a site colection with 80 GB after installing SP1 and using the stsadm am i able to split it across multiple DB's , if yes which DB is the active one for storing new content and what about the Content types,shall i still make use of them as i was originally doing once i had one Db with 80 GB size

my email is sassaf@netways.com , i would appreciated a lot if i can get any feedback of my issue raised above
at 12/5/2007 2:12 PM

Re: Nice Article

A site collection cannot exist in multiple ContentDBs.  It must exist entirely in a single ContentDB, no exceptions.  So you can't use this command to change that.  If there were other site collections in the same ContentDB you could move the rest out.  That's about as close as you'll get unfortunately.

tk
Todd O. Klindt at 12/5/2007 2:20 PM

Use for Migrating?

Thank you - exactly what we need , I think. Can the same process be used to migrate a site collection to a different web app or farm?
We have a customer with a site collection that is currently hosted in a web app running in the Account Creation mode.  If we were to back this site collection up and move it to a database in a farm that is in regular mode are there any implications or adjustments that will need to be made?
Thanks,
a
at 12/11/2007 10:14 AM

Re: Use for Migrating?

I haven't dealt with hosted mode in SharePoint any, so this is mostly guesswork.  Can you just use STSADM -o backup to back the site up and use STSADM -o restore to restore it to a new location?  That would be the first thing I'd try.

tk
Todd O. Klindt at 12/11/2007 10:44 AM

Site collection owner requirement

I also noticed that user running the command needs to be a site owner otherwise stsadm errors out updating the sitemaps table in Config db.
at 12/27/2007 1:02 AM

Great Post

Thank you, you saved me weeks of work :-)
at 1/31/2008 9:47 AM

Indeed a little gem - Used and worked

I wanted to share that I used this command to split a database to a 20 Gb database and it worked great. Microsoft recommended to try this command because there's a blog about the STSADM (backup, deletesites and restore) and has a note that only supports databases up to 15 Gb.

Something to consider also, be aware of the disk space when using this command, because the log grows as big as the database.

Thanks for the post!
at 2/4/2008 9:39 AM

thanks alot

i followed your article and i did it , yes i've moved a site collection from its content databse to another one , without the neeed to oncrease or decrease the allowed number of site collections per content databse . it was very smooth operation

thanks again
at 1/13/2009 3:18 PM

another site already exsists

Todd, when i do this command to mergeconentdbs, I get the error saying another site already exsists. I had created a brand new destination content db (from the CA GUI) and also i checked the permissions as per the technet article on this and found it to be correct.

How come the mergecontentdbs can complain that the site collection is already present?

i ran as follows
stsadm -o mergecontentdbs -url http://smallbuss/sites/sitename -sourcedatabasename MOSS_SB_Content1 -destinationdatabasename MOSS_SB_Content2 -operation 3 -filename sb.xml

RESULT:

http://sb/sites/sitename
Moving sites...
Another site already exists at /sites/sitename. Delete this site before attempting to create a new site with the same URL, choose a new URL, or create a new inclusion at the path you originally specified.


Any ideas
at 1/21/2009 5:33 PM

Re: Move Site Collections in a Single Bound

From the article:

One thing to note is that the –url parameter is NOT the URL of the Site Collection you want to move, it's the URL of the Web Application that the Site Collection is in.
at 1/23/2009 1:41 PM

Are sites available?

Quick question:  Is the site collection still available during the migration or is it unavailable from the stsadm command until the IIS restart?
at 2/17/2009 3:13 PM

Re: Are sites available?

I don't remember. The good news is that it's really easy to test.

tk
Todd Klindt at 2/19/2009 2:24 PM

Site already exists

Check your permissions - from technet

If you do not have the correct permissions to perform the operation, you will receive the following error message: “Moving sites... Another site already exists at /sites/test. Delete this site before attempting to create a new site with the same URL, choose a new URL, or create a new inclusion at the path you originally specified.”

Martin
at 2/20/2009 1:31 PM

Strange error

This works a treat, however, we have started to get a strange error on ONE of our WFEs since we moved a site collection with this method:

Event Type: Error
Event Source: Office SharePoint Server
Event Category: User Profiles
Event ID: 5555
Failure trying to synch web application faa3fdbb-c932-4a8d-9b52-a25e298c5772, ContentDB 4a88c940-f808-413e-b105-357bb10275f9  Exception message was A duplicate site ID 07c8ce7b-a805-4484-a675-6648729c2f89(http://sharepoint) 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.

Anyone else get this?  Is it worth running the preparetomove command anyway before doing the move?

steve
at 2/27/2009 10:29 AM

Are sites available?

They are still available (have just checked). However, I don't know what would happen if you opened and saved a doc during the move.

The risk of testing might be that it appears fine, but if a user changes something at the point that bit of data was moved, it would corrupt or worse?!

Any thoughts?  Maybe locking woudl be safest just in case?
at 2/27/2009 11:05 AM

Re: Are sites available?

To be safe you could lock the site collection to read-only or no access before you moved it.. That would prevent any corruption concerns.

tk
Todd O. Klindt at 2/27/2009 10:56 PM

where did you get your sharepoint hosting?

and how much did it cost? Do you use a datacentre? Is it your own server?

I cant find anywhere that will let me work on a dedicated server's file system at a reasonable price?

Any help greatly appreciated although i dont hold out much hope for controlling my own wss environment!

--email removed--
at 3/11/2009 6:15 AM

Re: where did you get your sharepoint hosting?

This web site is hosted by a server in my basement. I have DSL service with a business account. It offers 1.5 Mb up and down. That seems to work well enough for the amount of traffic I have.

tk
Todd O. Klindt at 3/11/2009 11:42 AM

Updated information on MERGECONTENTDB

FYI, words of caution, and an upcoming fix(!) on this command from Microsoft:

http://blogs.msdn.com/sharepoint/archive/2009/03/24/possible-issue-with-mergecontentdb-stsadm-operation.aspx

Unfortunately, this blog is a direct result of a human error interruption of the mergecontentdb command. 

It made for an interesting week...  :(
at 3/27/2009 10:53 AM

Re: Updated information on MERGECONTENTDB

I kept meaning to add a blog post about this and I kept putting it off. Thanks for keeping me honest. :)

tk
Todd O. Klindt at 3/27/2009 4:15 PM

mergecontentdbs success... with data loss

With the December 2007 release of SP1, a new stsadm command was introduced: mergecontentdbs. I had the opportunity to use this wonderful new command just a few weeks ago (saving my bacon from a rogue site collection which caused upgrade failure--fortunately I had the October 9, 2007, Security Update which gave me the mergecontentdbs command--SP1 upgrade would fail without getting rid of the rogue). Sadly, I learned a week after using the command in our production environment that it ever so conveniently deletes all content from lookup fields with multiple selections. Not even the versioning information is kept; the field only has to allow multiple selections; and, it even affects user/group fields! Talk about get egg on my face when I asked one of our groups where their data had gone!

Turns out, this specific problem is documented and corrected in the April 2009 CU (KB968857). Ironically, the KB was last updated just three days after I used mergecontentdbs and lost our data. Sure do wish something had been mentioned sooner than a year and half after initial release.
at 5/26/2009 12:56 PM

Scaling for the Tranasction log growth during mergecontentdbs...

Hi Todd, how much space should be allocated to your tranasction log size/drive, say for a 15 GB site collection migration from one content db to another content db using stsadm - o mergecontentdbs?   Is there an estimated growth known number/ratio for the transaction log during this porcess, i.e. 3 to 4 times the size of the site collection being migrated?  Thanks.
at 7/13/2009 8:14 AM

Add Comment

Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.

Title


Body *


Today's date *

Please enter today's date so I know you are a real person
Attachments