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?

Yes, I am storing those files on the same logical drive. That would definitely explain the fragmentation I'm seeing, so I'll have to do something about that. As I said, ALL of the exchange data goes onto this drive, the system drive is only for the operating system and files of that sort.
–
IceMageApr 26 '10 at 20:29

1

Bad, bad, bad. Not only for performance, but mainly for disaster recovery: you just don't want to lose both your database and transaction logs at the same time.
–
MassimoApr 26 '10 at 20:35

1

+1 In a perfect world, you want your OS on one volume, database on another volume, and logs on a third. I don't know how large your organization is, but you're taking a HUGE performance hit having the logs sit on the same volume as the EDB. The EDB is accessed with random reads, whereas the logs are sequential. The I/O and contention on the disk when you have everything on one volume is big. In my estimation, RAID-5 is good for the EDB volume, and RAID-1 for the logs.
–
HolocrypticApr 26 '10 at 20:47

Wow - cleaning up, I never accepted this, even though this was correct. The transaction logs being on the same volume was causing the fragmentation. I ended up not defragging, but instead re-constructing the raid with multiple volumes and that solved my performance issues.
–
IceMageJun 10 at 15:57

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.

Shadow copies won't exist, since it is actually a true hardware RAID, but you're both right as to the cause of fragmentation, the volumes are definitely not configured appropriately.
–
IceMageApr 26 '10 at 20:30

1

@IceMage, hardware (or software) RAID has nothing to do with whether or not Shadow Copies exist.
–
John GardeniersApr 26 '10 at 21:39

Microsoft's short description is "The Volume Shadow Copy Service provides the backup infrastructure for the Microsoft Windows XP and Microsoft Windows Server 2003 operating systems, as well as a mechanism for creating consistent point-in-time copies of data known as shadow copies." So shadow copies are used by backup software such as backup exec but also enable the previous versions functionality in the properties of a file/folder.
–
pplrpplApr 27 '10 at 14:01