Errors 5555 and 7888 in the event log

We wanted to change the content database location from the SQL netbios name to the SQL FQDN instead (apparently this improves performance of db access) - so we removed reference to the content databases in Central Administration and re-attached them. What we should have done first is used the stsadm preparetomove command before doing so, creating the following messages in the event viewer:

Event Type: Error
Event Source: Office SharePoint Server
Event Category: User Profiles
Event ID: 5555
Date: 24/07/2007
Time: 16:00:01
User: N/A Computer: EP-SP-FE01
Description:
Failure trying to synch web application 43caed9b-30c4-4b56-a5dd-3973ef92e354, ContentDB a5c17eb0-94bf-4362-87b1-be274bb5cc03 Exception message was A duplicate site ID ef4c600f-3069-4d07-9231-fd27fc72ef28(https://mysite/) 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.

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server General
Event ID: 7888
Date: 24/07/2007
Time: 16:00:01
User: N/A
Computer: EP-SP-FE01
Description:
A runtime exception was detected. Details follow. Message: A duplicate site ID ef4c600f-3069-4d07-9231-fd27fc72ef28(https://mysite/) 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.

Techinal Details: Microsoft.Office.Server.UserProfiles.ProfileSynchronizationDuplicateSiteIDException: A duplicate site ID ef4c600f-3069-4d07-9231-fd27fc72ef28(https://mysite/) 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. at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.RegisterSitesForSynch(Guid[] rgGuid, Int32 nGuids, Object dummy) at Microsoft.Office.Server.UserProfiles.SynchCollection`2.FlushAdds() at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.AddRemoveSites(String strFirstChangeToken, SPChangeToken lastChangeToken) at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.SynchContentDB() at Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter(Boolean fRethrowException, TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)

To resolve the situation we ran the following command on one of the front-end servers:
stsadm -o sync -deleteolddatabases 0

This sorted the problem, but it would have probably been better to use the preparetomove command in the first place. As to whether using the SQL FQDN improved performance or not - it didn't seem to make any difference whatsoever!