1

In the process of re-branding my client, currently running on MOSS 2007. Can't detach their live database, so decided on backing up the live, and restoring the DB to a new database.

Live is called WSS_Content_Live

Restore is called WSS_Content_Restore

Problem here is, I created a new application in Central Administrator without a site collection as the restored database already has a collection assigned. Under databases, I removed the default created DB and attached the restored database.

I've done this 100's of times before, but for some reason, with this client the restored database returns zero "0" sites. after restored.

I've tried resetting IIS in the hopes that it's a delayed response between sql and sharepoint but not such luck?

[Update]

So, I'm thinking SQL. Did a bit of investigation with our IT guys and found this

[Update 2]

The process in the link did not work. Found a solution to fiddle with the [config_db] but this is not an option for me, as I'm on the live environment and the live site needs to be active during this process.

[Update 3]

Managed to replicate this under a different environment. The problem is the ID that got assigned to the first application. Basically, I'm trying to restore Wss_Content_Live on SQL_Server_Live, to Wss_Content_Restored on SQL_Server_Live. A new database, on the same server that is hosting the original database. If we override the existing with the restore it works find, but for some reason, we are not allowed to restore the database under a different alias, as it returns 0 for the number of sites. The restoration of the database under the different alias success but the site count for the database, once attached to a new web application returns 0...

Improve this question

3 Answers 3

Reset to default
3

This is typical (expected) behavior. You cannot attach the same content database to the same farm twice. Renaming the database will not change the object GUIDs contained within the database, so when you attach it you're essentially attaching the exact same content to a second web application. SharePoint will be unable to translate between the two since all of the referencing IDs are identical, and you can't have a site with the same ID contained within two content databases on two different web applications. Typically you're prompted during the attach that items with the same GUID will be removed. This will work fine between farms, but you can't do what you're doing on the same farm.

Improve this answer
2
  • this is what i eventually assumed. but there must be a way (illegally) to modify what sharepoint interprets between the two applications? i found a solution to modify the configuration database, but as we know this voids the warranty on sharepoint...
    – JadedEric
    Commented Oct 27, 2011 at 13:33
  • You could use a third party migration tool to "copy" the objects from one web application to new instances on another web application, as that would physically create new items with new IDs. There's no way to do what you're trying to do with just a DB. You'd need to physically modify the content db (not the config db) and change all of the GUIDs, and the relationship between all of the objects; it's just not possible without using a second farm or a third party tool.
    – webdes03
    Commented Oct 27, 2011 at 14:48
0

I believe this issue has to do with the DB Name. Create a new DB with a different name and try restoring the DB.

Improve this answer
3
  • Deepu. I restored WSS_Content_Live to WSS_Content_Restore. the application ids are still the same :(
    – JadedEric
    Commented Oct 27, 2011 at 9:53
  • Is this restore being done on the same farm or in a different farm?
    – Deepu Nair
    Commented Oct 27, 2011 at 10:20
  • same farm. we played around with this on a development environment and replicated this issue there as well. see my update above for details.
    – JadedEric
    Commented Oct 27, 2011 at 12:53
0

You're not going to be able to restore a copy of a content database and attach it back to the farm it was created in unless you first detach the original content database from the farm. This is not possible in SharePoint 2007, because even if you rename the database to a different name, it still contains the same GUIDs in it as are used by the original content database. In SharePoint 2010 you can add the database as an unattached content database and extract content from it, but this is a new feature that is not available in SharePoint 2007.

If you want to copy the contents of that database within the farm that created it, your best bet is to use the site collection backup operation in STSADM to move the individual site collections in that database, I don't think that what you're trying to do with the full database is going to work. You may be able to run the PrepareToMove STSADM operation against the content DB before you back it up, but I don't even think that prevents the issue you're having...

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.