Question:
Can Diskeeper defragment a Domino server? What about the RRV table?
Answer:
All disk defragmentation occurs at the logical disk level. This means the MFT record for the file contains one entry for every fragment indicating its starting LCN address and its length. If a file is in 500 fragments there are 500 entries. The more fragments there are, the longer it takes to read the file.
Ideally, defragmentation software consolidates the file so it has one LCN entry in the MFT. Defragmentation software is hardware independent; all it needs to know is the file system (NTFS or FAT) and the disk size. Once the software defrags a file it is reported to the disk controller which maps the LCNs to the physical clusters on the drive. In RAID for example, this might mean striping a file across multiple platters. In this situation the file is read (logically) by the file system in a single logical I/O and it has the fastest possible access by the physical disk according to the controller software. This is a win-win. If the file were logically fragmented the system would need multiple logical I/O and the physical mapping would also be less efficient.
With respect to a Domino server the Notes database is just one big file to the defrag software. The Microsoft API for moving files lets us move open files, including databases, safely. We have a number of customers who routinely defrag Domino servers with no problem.
A good defrag product will have CPU and I/O throttling to minimize impact on users if you are defragmenting on an active server. Diskeeper provides InvisiTasking which allows Diskeeper to run in the background without impacting performance.
We see most of the Notes problems not on servers but on workstations. The replication feature shatters local Notes databases with an adverse effect on Notes launch time and application performance. Defrag software that consolidates the free space into the largest contiguous piece will slow re-fragmentation of the Notes database and mitigate the fragmentation from replication.
