Skip to main content

Do we need to file-level defragment Exchange database drives?

 Do we need to file-level defragment Exchange database drives?


Every so often there is a question: "Should we run file-level defragmentation software on Exchange servers?"
Usually, this comes from confusion that file system defragmentation actually helps Exchange as - well, Exchange databases get fragmented too.
The process of Exchange database fragmentation is a completely different story though - it is the defragmentation of the "white space" or empty database pages within the Exchange database. There are 2 types of defragmentation of Exchange databases:
ONLINE defragmentation - this is what happens as part of online maintenance which is by default run on nightly basis. Here we rearrange the data (database pages really) within the database to have more contiguous white space. Typically you will want to make sure that your backup schedule does NOT interfere with online maintenance schedule, as starting of online backup will stop the online defrag.
OFFLINE defragmentation - this is what happens when you run ESEUTIL utility with the /d switch - therefore you need to take the database offline to do it. This is typically done only when there is a specific reason to do it - such as reclaiming huge amounts of hard drive space, if instructed to do so by Support Services when troubleshooting a specific problem, or after a database hard repair (which is another thing that we should never do).
So - that being said - what about file system defragmentation?
I would never do it on running production server databases. The reason for it is simple actually - file system defrag is a very intense I/O operation. So the disc will be very busy. I have seen some cases here in Support Services, where our database engine has actually started logging warnings that the write to the disc was successful, but it took "unusually long" to complete, and it was suggesting that hardware might be at fault. Sure enough - a disk defrag kicked off just before this started happening as witnessed by the Application log. That right there is enough reason for me not to do it in real life.
The bottom line really is - you do not HAVE to file-level defrag the Exchange database drives. Exchange reads and writes to it's databases in very random fashion. Large sequential reads and writes will see much more improvement from file system defrag than Exchange databases will. But if you really WANT to do it - I would do it the old-fashioned way: move the databases off to some other volume, file system defrag the drive and then move the databases back... Or at least make sure you have a good backup, dismount the databases and file-system defrag then.
Few related things to read:
328804 How to Defragment Exchange Databases
http://support.microsoft.com/?id=328804
192185 XADM: How to Defragment with the Eseutil Utility (Eseutil.exe)
http://support.microsoft.com/?id=192185
256352 Online Defragmentation Does Not Reduce Size of .edb Files
http://support.microsoft.com/?id=256352

Comments

Popular posts from this blog

ما هى ال FSMO Roles

  بأختصار ال FSMO Roles هى اختصار ل Flexible Single Operation Master و هى عباره عن 5 Roles فى ال Active Directory و هما بينقسموا لقسمين A - Forest Roles 1- Schema Master Role و هى ال Role اللى بتتحكم فى ال schema و بيكون فى Schema Master Role واحد فى ال Forest بيكون موجود على Domain Controller و بيتم التحكم فيها من خلال ال Active Directory Schema Snap in in MMC بس بعد ما يتعمل Schema Register بواسطه الامر التالى من ال Cmd regsvr32 schmmgmt.dll 2-Domin Naming Master و هى ال Role المسئوله عن تسميه ال Domains و بتتأكد ان مفيش 2 Domain ليهم نفس الاسم فى ال Forest و بيتم التحكم فيها من خلال ال Active Directory Domains & Trusts B- Domain Roles 1-PDC Emulator و هى ال Role اللى بتتحكم فى ال Password change فى ال domain و بتتحكم فى ال time synchronization و هى تعتبر المكان الافتراضى لل GPO's و هى تعتبر Domain Role مش زى الاتنين الاولانيين و بيتم التحكم فيها من خلال ال Active directory Users & Computers عن طريق عمل كليك يمين على اسم الدومين و نختار operations master فى تاب ال PDC Emu

Recreating a missing VMFS datastore partition in VMware vSphere 5.x and 6.x

    Symptoms A datastore has become inaccessible. A VMFS partition table is missing.   Purpose The partition table is required only during a rescan. This means that the datastore may become inaccessible on a host during a rescan if the VMFS partition was deleted after the last rescan. The partition table is physically located on the LUN, so all vSphere hosts that have access to this LUN can see the change has taken place. However, only the hosts that do a rescan will be affected.   This article provides information on: Determining whether this is the same problem Resolving the problem   Cause This issue occurs because the VMFS partition can be deleted by deleting the datastore from the vSphere Client. This is prevented by the software, if the datastore is in use. It can also happen if a physical server has access to the LUN on the SAN and does an install, for example.   Resolution To resolve this issue: Run the  partedUtil  command on the host with the issues and verify if your output

Question كيفية عمل share للـ outlook conntact لكل الـ Domain Users

  الحل بسيط جدا عايز الكونتاكت تتحدث دايما بحيث انك لما تضيف يوزر جديد يسمع في الكونتاكت اول حاجه بتدخل علي in office 2003 tools --- email account ---- add address book --- internet directory service (LDAP) type your server name then login info . mark this server require me to logon type any user on active directory and its password then save and close outlook and open it again now you will find all your active directory users in address book