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.
No comments:
Post a Comment