Since 03/23/2009, the issue with STSADM –o mergecontentdb is officially documented on the MD KB: http://support.microsoft.com/kb/969242/.

This problem is particularly annoying because nowadays, with WSS/MOSS getting a huge adoption, it happens very frequently to have to move site collections across content database. More worrying, the corruption may occur in both source AND destination content databases. The only solution being the restore of the whole content database(s)!

MS still proposes two alternatives (well, I call them workarounds!)

• Use the Central Admin extension delivered as part of the Microsoft SharePoint Administration Toolkit v3.0 x86 : The Batch Site Manager.
• Use the old way consisting in performing a backup restore taking care of fooling SharePoint in order to place the restore in the content database of your choice, which means, in short:

1. Setting a lock on the site collection to be move (readonly or noaccess)
2. Backing up the site collection
3. If successful, deleting the site collection
4. Taking note of the site limit applied to all the content databases in the given web application
5. Lowering the limit on every content database except the destination one in order for the limit to be equal to the current number of site collection. for the destination CDB, add 1 or more to the limit
6. Restoring the site collection, it will automatically be restored to the CDB with the lowest number of site collections compared to the limit set
7. Removing the lock

More info over the issue:

• Post from MS Support: STSADM MergeContentDB possible database corruption
• Microsoft SharePoint Team Blog: Possible Issue with mergecontentdb STSADM Operation
• MS KB: The STSADM MergeContentDB command may cause database corruption in Windows SharePoint Services 3.0

And cut!