Our client has a database that has approximately 440K of documents, many with attachments. The database is distributed across multiple sites in a hub-spoke network. The question I have for everyone here is how to explain the discrepancy in filesize for the database: across the replicas of the database, it varies in size from 48 GB to 65 GB. Ironically, the largest copy has a smaller document count than the smallest copy.
Now, I know the size of the database is a major issue in and of itself. That is of course part of why we’re investigating this. But I’m posting here specifically because I want to get to the bottom of the mystery behind the variation in replica size for this database, so please focus responses on addressing that. What can account for such a wide range in size for replicas of the same database? We have already accounted for the following:
View index sizes are about the same on all of the replicas. No significant difference here
Examining doc sizes in each database, at least based on largest docs, does not show any missing docs between replicas. The docs missing from the largest replica do not appear to be any of the largest docs seen in all replicas.
Subject: Replicas of same database vary in size by almost 17 GIG. How?
White space is not replicated between databases – so if documents are deleted in one database and replicated only the deletion stubs are sent and not the white space the documents occupied. Each database will use up it’s own white space to store new documents, so sizes will start to vary
Subject: RE: Replicas of same database vary in size by almost 17 GIG. How?
I understand that some variation in size is to be expected due to white space. But 17 GIG?!? Nothing else we monitor on this client’s Notes network displays anything close to this kind of variation. Assuming 48 GIG is close to the accurate size with little white space, that’s a variation of as much as 35% of the database size. Is it normal to expect so much white space?
Subject: RE: Replicas of same database vary in size by almost 17 GIG. How?
Is it possible you have the Compact task scheduled on one server, and not the other? In that case one replica would be regularly purging the whitespace and the other wouldn’t. Check the"% Used" in the database properties on each.
Another thing to check is to create a view of All Documents in the database, with a totaled column for document size, to verify the actual space being used for data.