Unable to shrink database after stsadm -o mergecontentdbs

Written by Administrator

Monday, 30 August 2010 12:27

After using command stsadm –o mergecontentdb you are unable to shrink original DB for the space that should be already moved in another DB

The move works correctly and the “stsadm –o mergecontentdbs” command returns no error. Looking in the new content database you could see the data and an entry in the “sites” table. However you cannot shrink the old content DB as there is no free space in there.

So what was the problem?

It became clear that once the move is over, you are unable to shrink the size of the old content database. It still contains gigabytes of data.

Running a “stsadm –o databaserepair” command against the old content database shows you numbers of orphans and upon closer inspection these are 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.

You can find more info here:

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. If you cannot wait till this job (free disk space issue) you can run the stsadm -o databaserepair -url http://<URL_of_WindowsSharePointServices_Site> -databasename <name of database that contains the orphan item that is to be deleted> -deletecorruption

Be aware you need same space for DB log as your moved sites have.