Detaching Databases in MOSS 2007 Environments.
While performing database maintenance there are few things to consider and execute to keep your environment healthy. First being preparetomove, if you are detaching databases from a production environment this is a must.
The following line is extremely important so I thought I would make it bold :)
Any database that is attached to a MOSS 2007 farm and consuming from an SSP has to have stsadm -o preparetomove executed prior to the actual detach from the farm.
This is due to several reasons, the main being IT WILL break the relationship between your shared service provider and your database. This relationship can be repaired but it essentially means losing the part of your search index that relates to that database.
The full command is below.
stsadm -o preparetomove
{-ContentDB <DatabaseServer:DatabaseName> |
-Site <URL>}
[-OldContentDB <uniqueidentifier>]
[-undo]
For detaching databases cleanly from the farm we really only care about the first 2 switches. So your command might look like this.
stsadm -o preparetomove -contentdb SQLSERVER:DBNAME -site http://www.sharepointskills.com
Followed by the following command to actually remove your database from your farm.
stsadm -o deletecontentdb -url http://www.sharepointskills.com -databaseserver SQLSERVER -databasename DBNAME
When you want to reattach your database to the farm it’s only 1 step rather than the 2 step process.
stsadm -o addcontentdb -url http://www.sharepointskills.com -databasename DBNAME -databaseserver SQLSERVER
Essentially what this does is it tells the SSP that you are relocating this database and to prepare to get a new database GUID. It tells the system that the current GUID for databaseA is stale and that when this database name is picked up the next time in the crawl to replace its GUID. With doing that is shifts all of the Site information and index's for that database to the new database GUID.
If you fail to use this command prior to the move it will create a stale entry in your SSP and all sites going forward in the database will not be crawled. Additionally it will create a pretty ugly error in your web front end application log that looks similar to the following.
Failure trying to synch web application 09a21da5-4485-4b00-8268-772aea7fea12, ContentDB 65301403-c277-4b4c-ad5a-e822572d10ea: A duplicate site ID 3b3a4372-aa91-4e0c-ba57-2567958d81bb(http://portal/sites/test1) 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.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
This is wonderful it gives you a resolution! However there is much more to this resolution than what meets the eye.
First we need to find out which databases are currently not in sync, this can be done from a simple stsadm command on your SSP web front end.
stsadm -o sync -listolddatabases 5
This command will list all databases that have not synced up correctly with the SSP in greater than 5 days. Based on your schedule to index your age value may change. You may want to change this value to 10 or 15. The result set returned is a list of database GUID's and the date/time they were last synchronized. Now that we have determined the list we need to clean them up and get those guys synced. To do this we execute an stsadm command that sets all of those GUID's as old, then during your next index it will pick up the new GUID's for your production databases not currently being synced.
stsadm -o preparetomove -contentdb sqlserver:dbname -oldcontentdb <GUID>
where sqlserver is where your content is housed, dbname is any database in your child farm, and GUID is a guild from the list of non-syncing databases we generated with the command above.
Based on your crawl schedule wait until the next full crawl. Once it completes go back into your SSP and run the stsadm -o sync -listolddatabases 5 command again. Anything left can likely be removed at this point. You can remove what is left by running the following command.
stsadm -o sync -deleteolddatabases 5
this will delete all GUID entries in the SSP for anything that is out of sync for more than 5 days. You have now successfully cleaned all inconsistencies with syncing in your SSP. All out of sync alerts should now subside.
Remember use stsadm -o preparetomove before detaching a database and this will not be a problem!
Cory
