Back in SharePoint 2007 Service Pack 1, a new command “stsadm –o mergecontentdbs” was released to help administrators move a site collection from one content database to another. (Despite its name it doesn’t actually merge content databases, just moves the data from one content database to another.) This was fine as long as the size of the site collection being moved was not too big.
It might take several hours to perform the whole move for a large site collection. Plus if for any reason the job crashed out during its run you could be left with orphans in either of your content databases or neither of them in working state. See http://support.microsoft.com/kb/969242/ for more information.
Recently I helped a customer upgrade their SharePoint system to SP2 with the June 09 Cumulative Update and once this was done, to move a 20Gb site collection to a new content database.
The move worked correctly and the “stsadm –o mergecontentdbs” command returned without error. Looking in the new content database I could see the data and an entry in the “sites” table which showed that this contentdb did in fact contain the moved site collection. Looking in the old contentdb at its “sites” table indeed showed that the site collection was gone.
So what was the problem?
It became clear that once the move was over, we were unable to shrink the size of the old content database. It still contained over 20Gb of data and I had no idea why it was still there.
Running a “stsadm –o databaserepair” command against the old content database showed 1000’s of orphans and upon closer inspection these where all individual sites (SPWeb objects) which had been part of the moved site collection. Running “stsadm –o databaserepair” this time again with the “-deletecorruption” switch did the job of removing the orphans after which we could shrink the old content database.
Therefore it would seem that the way the “stsadm –o mergecontentdbs” command works between SP1 and SP2 + June 09 CU seems to have changed. Indeed it seems to deliberately create orphans as part of the move.
After speaking to some of the guys on my team (hat tip to Andy D) the following blog posting came to light from the team at Microsoft who maintains the documentation you see on TechNet.
http://blogs.technet.com/tothesharepoint/archive/2009/05/21/3244169.aspx
It makes mention of the way the mergecontentdbs command was changed in the April 09 Cumulative Update and that it is now the default behaviour to leave the data in the old content database and rely on a new timer job to delete the data automatically in the background. The role of this job is to simply clean up orphans of a particular type which are generated as part of the call to mergecontentdbs.
In summary: Systems which have at least Service Pack 2 and the April 09 Cumulative Update will by default rely on a timer job to remove data from old content databases when the “stsadm –o mergecontentdbs” command is used to move a site collection from one database to another.