4

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?

IceMage
  • 1,336
  • 7
  • 12

3 Answers3

3

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.

Massimo
  • 70,200
  • 57
  • 200
  • 323
  • 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. – IceMage Apr 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. – Massimo Apr 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. – Holocryptic Apr 26 '10 at 20:47
  • Also having mail queues there really doesn't help... – Massimo Apr 26 '10 at 21:03
  • 1
    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. – IceMage Jun 10 '15 at 15:57
2

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.

Massimo
  • 70,200
  • 57
  • 200
  • 323
  • That's an interesting suggestion, one I may follow with since I need to logically separate the transaction logs and the database files. – IceMage Apr 26 '10 at 20:35
1

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.

  1. 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.

  2. I'm not sure on the speed/time calculation. I'm a little too busy to try doing the math.

pplrppl
  • 1,262
  • 2
  • 14
  • 23
  • 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. – IceMage Apr 26 '10 at 20:30
  • 1
    @IceMage, hardware (or software) RAID has nothing to do with whether or not Shadow Copies exist. – John Gardeniers Apr 26 '10 at 21:39
  • You may want to read http://www.windowsnetworking.com/articles_tutorials/Windows-Server-2003-Volume-Shadow-Copy-Service.html as it explains shadow copies and has a few decent screenshots – pplrppl Apr 27 '10 at 14:00
  • 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. – pplrppl Apr 27 '10 at 14:01