The task of the day was quite basic for a SharePoint admin: “move a content database from one SharePoint environment to another”.
The only requirement was to keep the initial environment live so that we could continue using it while finishing configuring the target environment, therefore we could not stop the access to the content on that one.
The new server is a different web application (therefore URL), site collection and content database name.
For the purpose of this article let’s call the environment “OLD” and the target environment “NEW”.
Both environment comprises of just one SharePoint 2010 Enterprise server (index and web front end) and one SQL 2008 R2 dedicated server for simplicity.
Standard steps to achieve this should be :
- On the OLD SQL Server:
- Backup the content database to file
(no need to disconnect the site collection from content database as we need to keep old server up and running too)
- On the NEW server’s Central Administration:
- Create a new content database. eg. SharePoint_Content
- Switch new content database Online and any other databases Offline (this ensures that any new site collection created will be stored on that new database)
- Create new site collection
- Switch back new content database Offline and the main one online
Now that the new empty database exists on the new server, let’s restore the content of the old server’s database into the new one.
- On NEW SQL server
- Copy the old database backup file into the new SQL server
- Select new content database and restore it
- From the old content database backup file (“restore from device” in SQL studio)
Now check the content of the NEW site collection which should show everything from the OLD database.
- Open Central Administration, Application Management, “View all site collections”
- Select the newly create site collection.
From that page it should show the content database associated with that site collection as below
Here comes the problem:
in my case the site collection showed up as associated with
, making the site collection unusable.
Re-linking a site collection to a content database can be done in PowerShell or STSADM but since our Site Collection already had this association before we restore the content it was just a question of refreshing that association:
In Central Administration :
- remove the content database from the list (removing it only “disconnects it” but doesn’t delete the physical database in SQL)
by opening “Manage Content Databases” from “Application Management and” (write down the name of that database before proceeding, for the next step)
- now add that same content database to the SharePoint Content databases list (type the name you wrote down)
- Go to “View all site collection” and check that the site collection is now re-associated with the correct content database it was initially.
It seems that when a database is restored on the SQL side SharePoint got confused and lost its balance which caused the content database to disconnect itself from the site collection(s), re-adding the database manually in Central Administration only revived that association and all went back to normal.
Clearly the best practice would have been to disconnect the database from SharePoint before doing this migration and reconnect it after but in my case I had to keep the old system up and running.
Is this a bug or forgotten step by SharePoint in the restore background process ?
It appears that the database restored to the new environment was from a Sharepoint environment with a higher CU, which may have caused the split between database and site collection.