Friday, August 29, 2014

DBMT compact optimization in action.

Here is a video showing the new DBMT compact optimization in action.

Let us know if you've got any questions. We hope you like it.

Thursday, August 28, 2014

How to make DBMT 50%+ more efficient

DBMT is a wonderful new feature in Domino 9, but it has a nasty habit of doing more work than it needs to.

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

Friday, August 22, 2014

Flashback Friday: Compact -c and fragmentation

Each Friday we going to present some of our older blog postings that covers a topic that we still get questions on.

In this week's flashback we are going to look at compact -c and how it fragments databases. Remember that under the covers DBMT does a compact -c


Tuesday, August 5, 2014

Anyone know what happened to Project Hawthorn ?

I've been looking but haven't heard Boo about this for months ? Is it dead ? Does anyone know ?

Thursday, July 24, 2014

IBM brings in the wrong Ed !!

I thought we wanted Ed Brill back not Connect - Ed !!!

No Auslug this year - from one of the Best to a non-event in three years.

It was rather sad to hear today that there will be no Auslug this year. I'm not sure why but my best guess is the ecosystem that was IBM Lotus in Australia is now so ill that a free event just can't be supported. I've written about this previously.

As previously mentioned, the people that try to organise these events do an amazing job but it all comes at a cost. They need vendor support and vendors need customer who are willing to buy stuff.

The committee is trying to put together an event for 2015 after ConnectED. I wish them all the best and can only hope IBM can regenerate mind share with mail for what is left of 2014.

Would people pay to come to an event. I'm not sure, what do you guys think ?

Friday, July 11, 2014

Busting a DBMT pre-allocation Myth

Some say you no longer need to worry about fragmenation now DBMT has a new pre-allocation feature - sorry that's not the case. Let me explain:

DBMT uses copy style compacts when it's reorganizing a target database. We've written numerous times about how copy style compacts have a nasty fragmentation side-effect. See here and here and here. IBM must of been listening to us because they attempted to address this with new pre-allocation functionality in Domino 9.0.1. 

The concept is that DBMT asks Windows to pre-allocate a file as contiguously as possible and then uses this space to make the copy.  Sounds great and a vast improvement over the previous method, but can you see the problem ? 

You spotted it right ?

That's right, this works great as long as your freespace is contiguous, and the only way that's going to happen is if you have a defragmentation product mopping up the mess that routinely results from running Domino. For early adopters of the DBMTas it was delivered in 9.0, prior to the pre-allocation improvements in 9.0.1, it is a case of half closing the gate after the horse has bolted, as they will already be suffering the negative effects of serious database fragmentation as a result, unless of course they had Defrag.NSF installed.

Even with DBMT available we still see customers  using compact -c (old habits die hard). The other major fragmentation contributor is full text indexing and we have written about it before. FTI will scramble the volume's freespace.

So what are we saying ?

Simply this, if the freespace is scrambled then DBMT preallocation is going to produce fragmented files, It can only deliver optimum results if contiguous freespace is available, and that's only going to happen if something is actively defragmenting it.  And for that we recommend Defrag.NSF (shameless product plug). 

So it's interesting to note that the pre-allocation functionality, introduced to help reduce DBMT related fragmentation works even better when Defrag.NSF is installed.
Thanks for reading.