The new DBMT tool is great. However, I am a bit worried about the copy-style compact operation which is performed. Our servers are running DAOS and archive style transaction logging. A copy-style compact forces a new DBIID after the db has been compacted. This means that we have to make a full backup of the db’s after DBMT has performed it’s compact operation. This is not very desirable. I would like to see an option to have the compact operation to run an in-place compaction (which has been the recommended option).
I am aware that the DBMT compact can be disabled, by adding the option “-compactThreads 0”, but I only see this as a workaround, as we would like to have an in-place compaction to take place as part of the regular db maintenance being carried out by DBMT.
Subject: inplace changes the dbiid as well
unless you just want to recover lost space (no file shrinkage). Unfortunately we don’t have a good response for backups w/ the dbiid changing since the backup vendors don’t have a standard api for us to use to spin off a backup of the database. Ideally they tie into the dbiid changing and kick off the backup, but I’m not aware of any that do that today (unfortunately).
We’ll have to investigate a way to do that backups as part of dbmt for those running archive style txn logging.
–Steve
Subject: Even IBM doesn’t do that
Ideally they tie into the dbiid changing and kick off the backup, but I’m not aware of any that do that today (unfortunately).
Well, even IBM doesn’t do that. 
We’ll have to investigate a way to do that backups as part of dbmt for those running archive style txn logging.
Any news about this? For now those couldn’t use dbmt, correct? An option to do copy-style-compacts only on a given day would help.
Kind regards,
Oliver Regelmann