Understanding SharePoint - Part 5 - Keep those webs small if you must use SMIGRATE
Understanding SharePoint - Part 5 - Keep those webs small if you must use SMIGRATE
This is the fifth post in a series in regards to "Not being mislead by what your seeing :)"
DISCLAIMER: This post may include steps that guide you through issuing statements against your SharePoint content databases. By no means does this mean that you should change any thing in the database. This is simply for "READING" values, and even this should be done during Off-Peak hours.
The Scenario
You have a sub web of a site, and it's a whopper. Let's say it's about 25GB :) Perhaps you want to relocate it to it's own site collection, or you need to move it around in the hierarchy. The only way to do this is via SMIGRATE as my post titled Moving a web and preserving permissions using SPUserUtil describes.
You kick off a SMIGRATE to export the web, and it eventual fails with possibly an access violation.
Unlike STSADM, which chunks the individual records of a site collection to the backup file, SMIGRATE allocates memory for caching the overall manifest of the export. SMIGRATE could require up to 3 times the amount of memory needed to generate the manifest data. The data is not chunked as in STSADM, but rather generated in memory and then persisted to the export file.
It generates the manifest file in UTF-8 format for use later to read it back in. It also generates in another format for use with XML compilation internally, which could lead to needing generally 2x the amount of memory as the first allocation, thus making the necessary memory requirement around 3x.
As you can see, trying to SMIGRATE our 25GB scenario sub web could possibly require around 75GB of virtual memory, and most systems would never have this. Besides, you would still be limited by the amount of addressable memory on a 32 bit system, as is Windows 2003. Thus, at most, there is a 2-3 GB address space for user mode applications depending on your servers setup. The entire web could never be exported if the overall size of the memory requirement during the export exceeded 2-3 GB, and that's if you happened to be fortunate to not have anything else running on the server that day and the planets aligned just right.
In Conclusion
If you have to use SMIGRATE routinely to move webs, then keep them small. Otherwise, you may need to use something to export your files out to reduce the webs size, to then move them, and then import the items back in, thus losing original time stamps, user associations to document and list items, etc.
Hope this helps!!
- Keith
Previous Posts on this series:
Understanding SharePoint - Part 1 - Understanding the SharePoint Portal Server Indexer
https://blogs.msdn.com/krichie/archive/2006/07/20/672755.aspx
Understanding SharePoint - Part 2 - The Infamous Query Plan Bug and The Origins of SPSiteManager
https://blogs.msdn.com/krichie/archive/2006/07/20/672755.aspx
Understanding SharePoint - Part 3 - Just because your database is larger doesn't necessarily mean that your index size will be
https://blogs.msdn.com/krichie/archive/2006/07/20/673339.aspx
Understanding SharePoint - Part 5 - Lock those sites before performing backups to prevent orphaned entries! -
https://blogs.msdn.com/krichie/archive/2006/07/25/678040.aspx
Additional reference material:
Administrator's Guide for Windows SharePoint Services - Migrating and Upgrading Web Sites
https://www.microsoft.com/resources/documentation/wss/2/all/adminguide/en-us/stsf12.mspx?mfr=true
Disaster Recovery in SharePoint Products and Technologies - Recovering Individual SharePoint Sites
https://www.microsoft.com/technet/prodtechnol/sppt/reskit/c2861881x.mspx
Backing Up and Restoring Web Sites
https://office.microsoft.com/en-us/assistance/HA011608261033.aspx
SPSiteManager is contained in the The SharePoint Utility Suite at:
https://www.microsoft.com/sharepoint/downloads/components/detail.asp?a1=724