SharePoint Content Deployment - Target Database Grows too Large

Wednesday, 5 March 2008 00:11 by RanjanBanerji

In my previous post I talked about setting up content deployment jobs in such a manner so that if you had to aggregate some jobs you would not trigger a full deployment.  You may ask why is a full deployment a problem?  Well I see two problems right away:

  1. If you created smaller jobs to avoid a single large job, then after aggregating your smaller jobs you trigger a full deployment, you just lost your attempt to avoid a large content deployment job.
  2. When a full deployment occurs the destination database grows to be larger than the source.

Say what?  What was that point number 2?  The destination database grows larger than the source?  How can that be?  Shouldn't the destination be the same size or smaller than the source?

Apparently not.  Imagine if you have a source application with a single document and just one version of it.  When you do a Content Deployment from this application to a destination application the destination will also have the one document as version 1.  Now if you do a full deployment (the option that says: Deploy all content, including content that has been deployed before of this job again) you will still have the one document and its one version at the source application but your target application will have the one document and two versions.  Hence the larger database size.

When this issue was put in front of Microsoft the response we got was turn off versioning at the target system.  Well there are two problems with that approach:

  1. There is no single switch that will turn of versions in every list and library.  So you have to write a script using the SharePoint object Model to do so.
  2. A full content deployment overwrites your version settings and turns them back on if the source database has versions turned on.


So what is one to do?  Well, after the first full deployment you need to:

  1. Write a script that will turn off versions on all lists and libraries in your target application.
  2. Never do a full deployment to this application


Now you can control the growth of the target application database.  One would think SharePoint offered some of these features right out of the box.  But if that happened then how would some people classify SharePoint as a development platform.  LOL


Categories:   SharePoint
Actions:   E-mail | Permalink | Comments (1) | Comment RSSRSS comment feed


May 15. 2008 12:21

Fadi Noja

Thanks, I followed you instructions and it works fine.  I've actually put up on my blog the script that turns off versioning (

Fadi Noja

Add comment

(Will show your Gravatar icon)

  Country flag

  • Comment
  • Preview