Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.
For more information and upcoming events around #dominoforever, please visit our Destination Domino Page
Copy-style compact is quite wasteful, in regards to disk space.
If multiple threads are used, an administrator has to make sure that n(threads) largest databases is available as empty space.
For example:
if DBMT is using 4 threads for compact, the 4 largest databases may add up to 250GB. Such a scenario could mean that an administrator is either forced to use less threads, or has to make sure that the disk volume isn't used more than e.g. 65%.
Hence, adding more compact options means real monetary savings!
An inplace, file size reduction compact via -B would not solve the problem. the database would still almost completely re-written.
The best compact is a DBMT pre-alloc compact.
You don't need a nightly compact. At most you should run a compact once per week if you have DAOS enabled and NIFNSF.
In many cases a compact every second week would be perfectly OK.
I would vote the other way round to have compact support the DBMT style compact option with pre-alloc.
Daniel Nashed
HCL Lifetime Ambassador
[https://blog.nashcom.de]
DBMT using "copy style" compacts also makes it bad for systems that use "snapshot" backups as it makes the "file system change delta" much bigger than it could be.