Our tests show that it can spend a considerable amount of time compacting databases that just DON'T need to be compacted. Even if there is no space to recover in a given database DBMT will still compact it according to the -compactNdays setting. In production this could equate to a huge number of databases and possibly hours of processing.
Why do all the work of manufacturing new "copies" of possibly hundreds of databases for no gain? On top of that resource wastage, all those databases will undergo DBIID changes and now require backing up to maintain a usable Transaction Log, the backing up process will then take longer because files that may have been contiguous will now be fragmented, if you are NOT running Defrag.NSF you now also have substantially increased server I/O and read times during the necessary backup process.
We know there a boundary cases, but in general you'd think it's best to do the compact part of a DBMT run only when there are disk space savings to be made. That's why we have now added the functionality to Defrag.NSF's DBMT tab.
On the DBMT Schedule tab integrated with Defrag.NSF you can now specify what percentage of freespace a database should have before it is considered to be a candidate for compacting. A simple and yet super effective improvement.
 |
| DBMT Settings |
With this new option in place, DBMT spends significantly less time compacting databases that just don't need compacting - less I/O, less load, less fragmentation and less changes to Database Instance Identifiers requiring backups. Any databases that do get out of shape with fragmentation are automatically defragged immediately after DBMT has completed it's work.
For more information on Defrag.NSF check out our Website at www.preemptive.com.au/defrag
No comments:
Post a Comment