Following are some scenarios where you may have to clone the Content Databases because of the Site Collections being so large that you can not use Site Collection backups as they are unsupported for Site Collection sizes over 100GB.
I am referring the Content Database with 'top-level' site collection as a 'root Content Database', the rest of content databases existing in Web Application as 'Additional Content Database'
Following are situations in this blog post discussion:
- You may have large Site Collection (>200GB) existing in Root Content Database that you want to move to its own content database.
- You may have a large Site Collections in a non-root content database co-existing one or more Site Collections that you want this site to be moved to its own Content Database.
- You may have a large site collection over 200 GB existing in a Web Application (A) that you want to move it to another Web Application (B)
- You may have a Web Application (A) with a root Content Database having a large Site Collection that you can not take backup of it by any method, and you have a requirement to decommission this Web Application (A) and migrate existing Site Collections to another new or existing Web Application (B).
- You may have a requirement to move numerous Site Collections that it is difficult to take backup of them by any available methods, to a separate Content Database. So, as a workaround, it may be easy to duplicate Content Database and delete unwanted site collections in either Content Database. Or it may be that, you may have to migrate numerous site collections from one Content Database to other Content Database, that you may think it is easier to clone Content database and mount it with AssignNewDatabaseId rather than working with stsadm/PowerShell Site Backup and restore operations.
Content Databases:
As we knew that every SharePoint Content Database has a Unique Id and the Content Database ID will be saved in "Database Information Table" in Content Database. Also, when a New Site Collection is created in any of the Web Application, or an existing Content Database is mounted to the SharePoint Farm, the 'Objects' table in Configuration Database gets updated with the 'Database ID' and 'Site Map' table gets updated with the 'Site Collection' details with URL mappings, Web Application and Content Database details.
As we knew that every SharePoint Content Database has a Unique Id and the Content Database ID will be saved in "Database Information Table" in Content Database. Also, when a New Site Collection is created in any of the Web Application, or an existing Content Database is mounted to the SharePoint Farm, the 'Objects' table in Configuration Database gets updated with the 'Database ID' and 'Site Map' table gets updated with the 'Site Collection' details with URL mappings, Web Application and Content Database details.
As a default SharePoint Architecture,
- A cloned copy of an existing Content Database can not be attached to the Same Farm. SharePoint returns error saying that another Database is already existing with same Database Id. But, Mount-SPContentDatabase allows you attach a cloned database with –AssignNewDatabaseId option. But unfortunately, any site collections existing in the Content Database have the same 'Site Id', then they become orphaned and will not showup in the Central Admin's Site Collections list. Also, upon mounting the 'Site Map' table will not get updated with the Site Collections information having conflict with existing Site Ids.
- An existing Site Collection cannot backedup and restore with different name to the Same Web Application. SharePoint returns error saying another Site Collection exists with Same 'Site Id'. But, you may allowed to restore the backup in a different Web Application with same or different name.
Following is a workarounds to overcome issues with 'Site Id' Conflicts if you are trying to duplicate a content database and you want to keep one unique Site Collection in each Content Database and avoid conflicts with 'Site Ids', using –AssignNewDatabaseId.
- First make a duplicate of the Content Database.
- After verifying the backup copy, delete the site collections existing in the Original Content Database.
- Detach the Original Database.
- Mount Cloned copy of Original Content Database using Mount-SPContentDatabase with –AssignNewDatabaseId option. This will allow the New Database be be attached to the farm without a conflict of Database Id.
- Delete the Site Collections those you want to keep in Original Content Database and don't want them in the Second Cloned Copy of Content Database.(Optional Scenario-1)
- If this Cloned Content Database is likely to be attached as additional Content Database to the same Web Application, then delete the Top-Level Site Collection.
(Optional Scenario-2) - If this Content Database was a root Content Database and if you are trying to attach to another Web Application, then Delete Top-Level Site Collection and Re-create as New.
- After making sure you have unique Site Collections in both Content Databases, Attach Original Content Database.
To Conclude, AssignNewDatabaseId will only sets a New Database ID to the Content Database, but it will not set new 'Site Id's for existing site collections. So, you will have to work with several additional steps to not to make site Collections orphaned. Please also make a note that the workarounds may or may not not work in all scenarios and they may not be fully supported by Microsoft.
Note: Please do not duplicate/Clone (Backup Database and restore with different name) and attach to the farm using -AssignNewDatabaseId parameter without having a thorough understanding of the SharePoint Architecture at Site Mapping functionality and Configuration Database level. Workarounds explained above are for specific scenarios are validated against out-of-the box Site Collections having no customization. So, the workarounds may not be applied in your case and may leave your sites as orphans and also may cause an unrecoverable damage. Please consult an experienced professional for best guidance in your case.