Lotus Domino database replica growing faster than source database

Why is this question in Wireless Network Cards & Adapters zone?

It was incorrecly assigned to the wireless zone - wireless connectivity is irrelevant here

If you compare both databases, how many documents etc. are in there?

Check the Log database, Usage, By Size, it contains for all databases the size of the views, updated at 5 AM. If you have the Catalog task running, you can find a lot of info in the catalog.nsf database as well. That database is usually updated during the night as well.

According to the catalog.nsf on both the source and replica server - (updated this morning around 1-2am) here is the following information:

Source Server:
Database size: 1,756,691,456
Number of documents: 1292
Number of design documents: 611

Replica Server:
Database size: 68,327,309,312
Number of documents: 1292
Number of design documents: 615

I cant see anything significantly different in the log database with regard to the various view sizes either.

Ok status update - at the moment the mail file replicas seem to be stable and in-line with eachother.

This is what I have done:

1. Stopped the update task on the replica server
2. Performed fixup, updall -R and compact -C on the replica database
3. Restarted the update task on the replica server

Since then (about 2-3 hours ago) both replicas on the source and replica server are about the same size, give or take a few MBs, and contain the same number of documents. Scheduled replication appears to be happening normally as well.

I'm going to leave this until the morning and see if things are still stable before taking any further action.

Unfortuantely I spoke too soon - the databases have once again grown and I have since had to do a fixup, updall and compact on them again this morning.

Attached are screenshots of views and properties of both the replica and source database.

Any other ideas?

I checked your document, indeed quite strange. I'm afraid this is a topic you really have to ask Lotus about.

Any clustering involved?

Yes clustering is involved - the source server is clustered with another server running the same OS and Domino version. The replica database is also clustered with another server running the same version of Domino.
As already stated, other mail files are setup in a similar fashion and dont show this behaviour - so there must be something specific to this database that is causing the issue.

Try:
Compare all db properties with the other, normal db.
If it's a standard mail db, replace its design using mail template.
Is db included in anyone's roaming profile?

I agree with Sjef, this is too freaky for us :)
You should open service request with IBM.

Thanks Sjef

A - I have already tried and while the new source db copies remain more-or-less the same size on the source clustered servers, they still grow on the replica servers.

B, C, D - I will look into during the course of the day

Thanks again :-)

Ah, of course, B (and the others) should be completed by executing the necessary repair operations. Just for the record...

Before trying the options above I have done the following:

1. Delete the replicas from the replica servers
2. Performed maintenance (again) on the source db
3. Instead of creating the new replcas on the replica servers by using the Notes client (File > Replication > New Replica) I have created the replicas using the admin process in the Domino Admin client
The new replicas were complete at 09:37 this morning and so far (at 14:30) the replica sizes are holding steady, whereas previously they would have ballooned at least 10-fold by now.

Fingers crossed...if this fails, then I'll try suggestions above...

Would be weird if it solves the problem, for the Admin client is built on the same common layer as the Notes client. But, as I learned over the years, in the Notes world nothing is impossible...

Yes, it's basically the same thing, the only difference is that the replica creation process is triggered by the server.
It all boils down to Domino console command, which calls Notes API function from nnotes.dll.

OK so the good news is that the database is holding steady at just over 1GB in line with its source. So looks like the following may have worked to resolve the issue, why I dont know!

1. Delete the replicas from the replica servers
2. Performed maintenance (again) on the source db
3. Instead of creating the new replcas on the replica servers by using the Notes client (File > Replication > New Replica) I have created the replicas using the admin process in the Domino Admin client
The new replicas were complete at 09:37 this morning and so far (at 14:30) the replica sizes are holding steady, whereas previously they would have ballooned at least 10-fold by now.

Thanks to all for their input

A combination of effort lead to this being resolved.

Fingers crossed!

Check whether someone scheduled a program in names.nsf.

E.g. this program document would produce the similar effect that you have:

names.nsf > Configurations > Servers > Programs

Program name:
     updall
Command line:
     "SubfolderOfData\Production\db.nsf" -C
Server to run on:
     The name of your "faulty" server

-C   option means that Update (indexer) task will update indexes of all unused views.

That means that all other view indexes are built because they are used, which again means that all db views are going to be built at all times, so the users will never have to wait for any view to be built.