locked
How "clean" is the end results of using stsadm -o mergecontentdbs RRS feed

  • Question

  • Platform MOSS 2007 service pack 3

    We need to move a site collection into its own content database on the same farm. We have web searched and found many articles that discuss this.

    What we have not seen, however, is discussion of the consequences of performing this action.

    1. Do the users see any difference with regards to the URL?  As far as I can tell, the answer to this one should be "no".

    2. After the move, are active alerts, workflows, solutions, features, custom web parts, etc. all still present and working?

    3. Are there any current dangers that should be taken into consideration?

    Thanks!

    Wednesday, October 31, 2012 5:51 PM

Answers

  • 1. The URL stays the same, you are simply moving site collection to a different content database (within the same web application).

    2. Yes, these features should remain and still work.

    3. Make SQL Server backups of the original content database before you start. This will be useful in probably 99% of the possible problems. Try not to power off your SQL Server while the migration is in progress. ;)


    Jason Warren
    Infrastructure Architect

    • Marked as answer by lwvirden Thursday, November 1, 2012 11:13 AM
    Thursday, November 1, 2012 1:56 AM

All replies

  • 1. The URL stays the same, you are simply moving site collection to a different content database (within the same web application).

    2. Yes, these features should remain and still work.

    3. Make SQL Server backups of the original content database before you start. This will be useful in probably 99% of the possible problems. Try not to power off your SQL Server while the migration is in progress. ;)


    Jason Warren
    Infrastructure Architect

    • Marked as answer by lwvirden Thursday, November 1, 2012 11:13 AM
    Thursday, November 1, 2012 1:56 AM
  • Jason, thank you for responding.

    1. I was hoping that was true - just wanted confirmation

    2.
    Good. We are evaluating a vendor product which layers a gui over stsadm
    and it warned that these would not remain. I was guessing that applied
    to moving a site collection to a different farm, and asked the vendor
    for further info. But since they had not replied, I was checking to make
    certain it wasnt something stsadm did that perhaps was not documented.

    3.
    Good idea. And while _we_ might not power off the server, mother nature
    is not always cooperative.  At least we are not close enough to the
    ocean to be flooded.

    Thursday, November 1, 2012 11:12 AM
  • Here are further notes on the mergecontentdbs stsadm operation page:

    Remarks

    Before you perform the Stsadm mergecontentdbs operation, you must:

    • Have available free space that is at least three times the size of the source site collection. Use the Enumsites: Stsadm operation (Office SharePoint Server) to determine the size of the site collection.

    • Ensure that data is synchronized between the profiles feature and the sites in the databases. To do this, run the preparetomove operation.

    In order to move a site collection from one database to another, you must be a member of both the Farm Administrators group and the Local Administrators group, and must have the Full Control permission granted for any site collection that needs to be moved. To grant this permission, in Central Administration, clickApplication management, and then Application Security, and then Policy for Web application. The account that you use to perform this procedure must be a member of the db_owner fixed database role in SQL Server.

    After the site has been moved successfully, remove or change your account permission level by using the Policy for Web Application page. If your account is used for other services, reset it to the original permission level.

    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."

    After the move is complete, you must run the iisreset /noforce command on each of the front-end Web servers in your farm. If a large amount of data has been moved, you may want to shrink the SQL databases and transaction logs. For further information on shrinking SQL databases, see How to: Shrink a Database (SQL Server Management Studio) (http://go.microsoft.com/fwlink/?LinkId=102959&clcid=0x409).


    Jason Warren
    Infrastructure Architect

    Thursday, November 1, 2012 1:52 PM
  • Thank you! Some of this info seems to be missing from the technet page for the mergecontentdbs, or else I have just forgotten that it is there.

    With regards to the preparetomove, isn't there a step that has to be followed that turns off the preparetomove after things are completed? Doesn't http://blogs.msdn.com/b/toddca/archive/2009/01/30/preparetomove-away-from-running-this-command.aspx talk about an undo flag?

    Just curious. I know that the last time or two that I detached or reattached the content database - from central admin - I ended up with things unsync'd and generating tons of event log entries.

    Thursday, November 1, 2012 1:58 PM
  • From Preparetomove stadm operation:

    Important Important:

    Before moving a site collection between content databases, the preparetomove operation must be run in order to ensure all user membership metadata are correctly preserved.

    I understand the concern, the blog post says not to run it (but then says to run it and after you're done moving it run it again with the -undo flag).

    Prepare to move ensures the profile information has been synched to the site collection/content database. This is similar to saving unwritten data to disk when shutting down your computer. You're effectively saying I I need to move this site collection so please make sure all of the data that should be in it has been saved"

    From a support standpoint, while the blog post is informative I would follow the instructions in the documentation (i.e. run prepare to move, move the site collection) so if something bad does happen Microsoft will be able to help fix it.

    The blog post says when moving a database, after it has been reattached the "Moving" flag is still true and running the -undo flag resets this. If after you run migratecontentdbs it still says moving, I would follow Todd's advice and run preparetomove with the -undo flag.


    Jason Warren
    Infrastructure Architect

    Thursday, November 1, 2012 2:40 PM