Copy of LN DB differs in size

[booltrue]

I have a 50GB DB on the server, when I do a copy on the server or even a local copy the size is only about 35GB
I figured out that issue long time ago, but for huge DB's it's quite a lot of memory space.

Is there any reason for that issue? The blocksize on the system should not cause such a huge memory space difference.

[Peter Klett]

The views need space. Open the copy and you will see that the database becomes bigger

[Tode]

The database size consists of:

1. Data in documents
2. Size of Design elements
3. View indexes
4. White space

When you create a new copy only 1. and 2. are the same (although the copy might have / not have document and design compression active, what can make a difference).
3. is built on usage (every view you open will increase the size of your database and every sortable column you click as well)
4. will be reduced automatically when creating a copy (as white space is not copied).

I am quite sure that Peter is right: in a big application view indexes can be almost as big as the data itself.

[booltrue]

I just tried to reproduce what both of you said.
I opened all views, clicked on each columns (all are sortable) and opened several documents,
but the size of the database is still the same. It didnt grow up, same as the original one
%used shows 99.9%

[Tode]

What about ODS? Are they both the same ODS?

[Ralf_B]

Well, also try to rebuild all views(ctrl+shift+F9) or open also the hidden views, the difference is most likely about the view index inside the database.
Compare %used  and the amount of documents between both databases.

The size for a copied / replicated DB depends also (except the already mentioned causes) on:

-  Index for views (if nisnsf is not used).
- Cluster size of the drive where the DB is stored.
- Amount of Profile Documents
- Unread Tables entries
- If documents have reader fields and documents does not get copied.
- Deletion stubs
- Replication conflicts
- Database settings like compression .......
- If the attachments are stored inside the database.

In the past I expected that databases have had a lot of year old deletion stubs which where not get deleted, but they where not recreated if a copy of the DB was created .......  especially if the DB' is really old and was created with Notes Version prior to 5 or 4.

[Pyewacket]

Does this behaviour apply to one specific databases or do
all of your databases of similar size behave the same?

[booltrue]

ODS version is same for both.

Also rebuilding the views didn't change the size of the copied db
source db size ~30GB, 49.5%used
copied db size ~16GB, 99.9%used
The amount of documents, unread documents and database settings are same for both dbs

Tried to remove the deletion stubs under the replication settings from the source db, but the size didn't change

The dbs are stored on the same cluster on the server. I also tried with local copies, but the same behaviour.

The behaviour applies to all other dbs same, even with only one view and size of ~60MB -> copied db size 2MB

In the past I expected that databases have had a lot of year old deletion stubs which where not get deleted, but they where not recreated if a copy of the DB was created

Could be the problem, but how to remove the deletion stubs, that apparently will not be recreated after copying

[Tode]

ARE YOU SERIOUS??

source db size ~30GB, 49.5%used
copied db size ~16GB, 99.9%used

What do you think, does "49.5% used" mean? Just compact the database with -c or -B to release the unused space...

[booltrue]

Ok, thanks.

Does compact can only be done from the console, or also from the database settings with "compress" ?

[Tode]

Yes, compress also works, if the database is not in use by somebody.

[booltrue]

Danke!

Weiß gar nicht warum ich die ganze Zeit englisch schreibe