The Scenario: I use a dedicated volume (RAID volume) to store all of my data for my Exchange 2007 server. Today, out of curiosity, I decided to check up on how fragmented the files on this data volume were. To my surprise, the answer is extremely. So, a three part question:
First and Foremost, SHOULD I defragment this volume (after a full backup of course)? Be specific as to why not if I should not, or reasons I absolutely should if I should.
Second, about how much time should I allow for during this maintenance period per gigabyte. The drives are all 7200 RPM SATA drives on a Hardware RAID 5 controller (Perc 5i/6i, can't remember), the files are extremely fragmented. (Over 5000 file fragments per gigabyte).
Third, is there something wrong here? It seems to me like the drive shouldn't be this fragmented. Could something be configured incorrectly that could be causing this to happen?
Are you storing database files and transaction logs on the same volume?
This would be a cause for such a fragmentation (and it would also be definitely not recommended).
Transaction logs are a lot of small files created on the fly, while the main database files grow continuously; this is an ideal recipe for heavy NTFS fragmentation.
I'm assuming there isn't anything else than an Exchange database on that volume... mail queues can also be a big source of fragmentation.
About defragmenting it: don't do it, if you can avoid it.
Do you have any space available, even on an external drive? Just stop Exchange services, copy everything somewhere else, format the volume and copy everything back again.
Or do a backup/restore, if you have proper backup software and devices.
In-place disk defragmentation is one of the slowest and more dangerous operations you can perform on a production system. And RAID 5 (which is quite slow at writings) really doesn't help here.
0/3. Is there anything other than the database files (*.edb and *.stm) on that volume? I guess you could say I'm asking how dedicated is dedicated. I once saw severe fragmentation caused by shadow copies being stored on an exchange volume. In smaller installations it's not uncommon to see index files, log files, smtp queue, mta queue on the same volume. Any of these would lead to fragmentation of the database files as well.
An OS defragment won't cause you a problem but if you don't have a huge amount of free space on the drive I wouldn't expect it to do much. I think you'd want to stop the information store service. Most documentation talking about defragging exchange is focused on logical fragmentation of white space in the exchange database not file level fragmentation. http://msexchangeteam.com/archive/2004/10/25/247342.aspx discusses this and mentions logging being confused about delayed writes during a file level defrag.
I'm not sure on the speed/time calculation. I'm a little too busy to try doing the math.