I know that reading the above you will say : backup and restore or export and import .
What if the procedure involves moving one BIIIIIIG Site > 15 Gb?
If you have the time to do it, that’s perfect. Just schedule the operations and go ahead.
Here is a method that will save you some time in completing this operation:
Say you have the webapplication http://myportal
Your customers create their sites under http://myportal/customers/subportal
CustomerA upgraded his contract , which entitles him to a full blown URL like http://MycustomerA and you need to port his data from Http://myportal/customer/subportalA to http://mycustomerA
On the old webapplication:
Create a new content database My_CustomerA_DB
open a command prompt on the Sharepoint Server and navigate to
%COMMONPROGRAMFILES %\Microsoft Shared\web server extensions\12\BIN and run :
stsadm –o mergecontentdbs -url http://myportal/customers/subportal
-sourcedatabasename WSSCOntentDB -destinationdatabasename My_CustomerA_DB
Mergecontentdbs- Stsadm operation (Office SharePoint Server)
After the operation completes, detach the My_CustomerA_DB from the old webapplication
If you have the infrastructure update installed (or later fixes) you don’t need to run the preparetomove command, see: Todd Carter's WebLog - PrepareToMove Away From Running This Command
Create a new webapplication for the Http://mycustomerA URL with a DefCOntentDB
Attach the My_CustomerA_DB to the new webapplication and remove the default DefContent DB
YAN (YET ANOTHER NOTE) :
“Under certain circumstances, the mergecontentdb Stsadm operation may fail. These circumstances include combinations of significant site collection size, user traffic, and SQL Server load. When the command fails, both the source and destination databases can be corrupted.
If you use mergecontentdb, make sure that you:
· Always back up both the source and target databases before using this operation.
· Set the site collection to be read-only before using mergecontentdb to move it.
· Refrain from cancelling the operation (either on the front-end Web server or the server running SQL Server).
· Run the command during off-peak hours, because mergecontentdb places significant additional load on the server running SQL Server.
Alternatively, consider using Batch Site Manager and the method described here. Because the Batch Site Manager works with site collections by using the Stsadm backup and restore operations with the –url parameter, we recommend that you not use Batch Site Manager for site collections larger than 15 GB.
The Batch Site Manager is included in the SharePoint Administration Toolkit:
· Microsoft SharePoint Administration Toolkit v3.0 x86
· Microsoft SharePoint Administration Toolkit v3.0 x64
Its a nice article , Liked it ,
Just followed all the instructions and it was great help . when i reattach my database with the new web app its says ready but number os sites is 0.
i try to attach the data base using stsadm and UI .every time it says number of sites 0.
Will appreciate you help .
I would also consider attaching the database using stsadm -o addcontentdb operation.
I have once encountered the 0 sies behavior but could not figure out where the error lies as the sites were still in the database, but they wer not recoignized upon attach.
Checking tha shareepoint logs from the attach timeframe should reveal more.
(sorry if this is a duplicate comment here - I think my browser bombed when I posted first time)
Worth noting that the line 'Set the site collection to be read-only before using mergecontentdb to move it' no longer appears in that blog. Nor does it appear in the reference KB article (969242).
Indeed locking a site as readonly (stsadm -o setsitelock -url...) will cause the mergecontentdb to fail with the following error:
[your site collection URL]
Another site already exists at [relative URL]. 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.
My testing shows that it copies the data to the target database (which could take ages for a large site collection), but fails to delete the data from the source database. Importantly, the farm still considers the site collection to be hosted by the source database. If you delete the site collection it deletes it from the source db but leaves all the table entries in the target db.
I am planning a site collection move using mergecontentdb at the moment and all I can do is tell the users not to use the site while I'm moving it (out of hours). For safety I am of course taking content database backups before (and after) the move. To mitigate the fact that I can't lock the site, I am also planning to take some metrics before and after the move by running select statements against dbo.AllDocs, dbo.AllLists, and each of those tables inner joined with dbo.Webs. Safer than just crossing my fingers and hoping, but not ideal.