Full deployment of content DB to other server results in larger DB - DavidCiarrocch

We have the problem of a destination content database growing large. We are
using the content deployment paths and jobs to copy one MOSS content DB from
one server (authoring server) to the staging and public facing MOSS servers.

The authoring server's MOSS DB is approximately 2.5GB in size, while the
staging DB has become 8GB in size and the public facing DB has become 3.5 GB
in size. We are doing full deployments once per week or more, and hourly
incremental deployments from the authoring server to the staging and public
facing servers.  New pages are only created on the authoring server so I
don't understand why the other two would be growing.

Why are the staging and public facing MOSS DBs growing in size compared to
the authoring DB? You would think that when a full deployment is done, it
replaces the content on the destination DB, but somehow they are growing.

Is there some kind of versioning or other option that is keeping old
records/copies of page on the sites resulting in differing content DB sizes?

Details on our scenario:
We have a SharePoint deployment consisting of 3 servers: an authoring
server, a staging server, and a public Internet facing server (the website is
an Internet facing site). We have SharePoint 2007 Enterprise version
installed on Windows Server 2003 SP2 on each of the three servers, each in
their own separate farm, each with their own separate SQL 2005 server
installed on each MOSS box.

David

Full deployment of content DB to other server results in larger DB - David

Here's an update to this problem:

I changed the SQL auto grow option from 10 % (default) to 50 MB and am
hoping that helps, but I don't think that is the problem.

The DB size problem is not with the DB log - we have the DB recovery model
set to simple so the log is emptied every time the SQL backup occurs. The
problem is the growth of the databaswe (.mdf file).

It seems that every time we do a full deployment, it adds to the destination
DB instead of replacing the DB content. The source database size is 2.54GB.
Every time we do a full deployment to the destination database (sometimes
incremental is not adequate  - we must do a full deployment to get it working
right) instead of replacing the data it adds an additional 2.5GB of data, as
if it's appending data to the database. At this point, after 4 or 5 full
deployments, the destination (staging) DB has grown to be around 10GB. I'm
probably going to have to delete and recreate the destination site DB and do
a backup/restore using MOSS so it starts again with the true size of the
database (2.5GB).

David

Hi David,We are experiencing the same issue only worse. - Bake

Hi David,
We are experiencing the same issue only worse.  We do a full export each
night and an incremental hourly.  I have already had to delete and re-create
our destenation content database once and it looks like I'm going to do it
again this week because our destination database has grown to 120GB!  I had
already come to the conclusion that the database is getting appended instead
of overwritten when we do a full deployment.

I'm going to open a ticket with MS and see what kind of information they can
share on this issue.  If I gain any valuable information, I'll let you know.

Alana

Alana,Thanks for your input. - David

Alana,

Thanks for your input.

I want to give you an update since you replied to my question. I opened a
case with Microsoft and they didn't have a fix to it. It seems to be that you
should only do a full deployment one time - the first time you deploy the
site, and only do incremental deployments after that.

They didn't charge me for the case by the way, and have confirmed this as a
but until then you just need to know to only do a full deployment one time.

If you want to discuss the issue issue or the Microsoft case I opened with
me directly, you can email me at david(at)txsys.com

Thanks

David

Full deployment of content DB - full disk - Peter B

Anyone know if there is an update of this issue/KB article?



We've been running full deployments nightly as the incrementals were failing occassionally (typical flaky Content Deployment).



Is our only option now to recreate a new content database and do a one-off Full?



Thanks.