Freigeben über

How to properly move (Detach/Attach) a content database.

  • Artikel

The idea to write this entry came as a result of many failed Profile sync operations I've seen lately, so, here it is:

As a scenario, let's assume that you have a webapplication you want to move on a different port. I stress the word move, because otherwise you could simply extend the webapplication on the desired additional port and you could be in business.So let's assume you want to get rid of the old web app and create a brand new clean one.

A very important step that is almost everytime forgoten is running the preparetomove operation (stsadm-o preparetomove that is).

What effect can this have on your server, you ask?

Well the simplest behavior you will almost for sure encounter is receiveing these errors hourly :

Event Type: Error
Event Source: Office SharePoint Server
Event Category: User Profiles
Event ID: 5555
...

Failure trying to synch web application <WebApp Guid here>,
ContentDB <Content Db GUID here> Exception message was A duplicate
site ID <Site ID here>(<site URL here>) was
found. This might be caused by restoring a content database from one server farm
into a different server farm without first removing the original database and then
running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove
command can be used with the -OldContentDB command line option to resolve this
issue.

Another behavior would be that you can have the usernames displayed funny, let's say by SID or Account Name (DOMAIN\Name), or the details not being updated as it should.

The error(s) are generated by the stale entries in the SSP db, in relation with the profile sync operation which runs hourly.

How to get out of this? Dont get into it in the first place :-)  !

Before performing ANY detach database operation from a webapplication consuming services from an SSP run the stsadm -o preparetomove operation https://technet.microsoft.com/en-us/library/cc263196.aspx

Second, if you are however there, follow the steps described in Cory's blog to get rid of the old associations in the sync job in the SSP: https://blogs.technet.com/corybu/archive/2007/06/01/detaching-databases-in-moss-2007-environments.aspx

in a nutshell :

in a command prompt:

  • run stsadm -o sync -listolddatabases 1 (it will display the databases that were not syncronized within the last 1 day)

for each of the guids above do:

  • run stsadm -o preparetomove -contentdb sqlserver:dbname -oldcontentdb <GUID> (this will set the guids as old in the SSP)

wait for the next sync job to to complete or..

to force a syncronization job to occur within the next 5 minutes run in a cmd window:

stsadm -o sync -SyncTiming M:5

Run

  • stsadm -o sync -listolddatabases 1 (to check if there are still databases left in an un-syncronizable state)
  • stsadm -o sync -deleteolddatabases 1 (to remove any other databases that might still be there in the profile sync job)

 At the end, set the syncronization schedule back to 1 H 

stsadm -o sync -SyncTiming H:1

Happy detaching/attaching :-)

Comments

  • Anonymous
    January 01, 2003
    Hi Dan, you are correct, performing a detach through the Central Administration UI will perform the preparetomove too. However, there are databases that cannot (due to size for instance) attached through UI. This can also happen while moving the databases between servers, etc.

  • Anonymous
    December 31, 2008
    Hi, Thanks for the tip.   Would performing attach/detach of content databases in Central Administration has the same effect of "preparetomove"?