Skip to main content

Defragmentation of Exchange Server Hard Disk is How!

 




I realized today this is one of the common question Exchange administrators ask and try to understand if it is a good idea or bad idea to perform file level defragmentation on Exchange servers. I don't remember where I got a hold of some nice notes about this topic; anyway I wanted to post here to share with Exchange community .Disk defragmentation involves rearranging data on a server's hard disks to make the files more contiguous for more efficient reads. Defragmenting your hard disks helps increase disk performance and helps ensure that your servers that run Exchange run smoothly and efficiently. Because severe disk fragmentation can cause performance problems, run a disk defragmentation program (such as Disk Defragmenter) on a regular basis or when server performance levels fall below normal. Because more disk reads are necessary when backing up a heavily fragmented file system, make sure that your disks are recently defragmented.

Exchange databases also require defragmentation. However, fragmentation of Exchange data occurs within the Exchange database itself. Specifically, Exchange database defragmentation refers to rearranging mailbox store and public folder store data to fill database pages more efficiently, thereby eliminating unused storage space.

There are two types of Exchange database defragmentation: online and offline.

Online Defragmentation

Online defragmentation is one of several database-related processes that occur during Exchange database maintenance. By default, on servers running Exchange 2000 Server and Exchange Server 2003, Exchange Server database maintenance occurs daily between 01:00 (1:00 A.M.) and 05:00 (5:00 A.M.). Online defragmentation occurs while Exchange Server databases remain online. Therefore, your e-mail users have complete access to mailbox data during the online defragmentation process.

The online defragmentation process involves automatically detecting and deleting objects that are no longer being used. This process provides more database space without actually changing the file size of the databases that are being defragmented.

Note: To increase the efficiency of defragmentation and backup processes, schedule your maintenance processes and backup operations to run at different times.

You can schedule database defragmentation in two ways


To schedule database defragmentation for an individual database, use the Maintenance interval option on the Database tab of a mailbox store or public folder store object.
To schedule database defragmentation for a collection of mailbox stores and public folder stores, use the Maintenance interval option on the Database (Policy) tab of a mailbox store or a public folder store policy. For information about how to create a mailbox store policy or public folder policy, see "Create a Mailbox Store Policy" and "Create a Public Folder Store Policy" in Exchange 2000 Server or Exchange Server 2003 Help.

Offline Defragmentation
Offline defragmentation involves using the Exchange Server Database Utilities (Eseutil.exe). ESEUTIL is an Exchange Server utility that you can use to defragment, repair, and check the integrity of Exchange Server databases. It is available through the following sources:

If you are running Exchange 2000 Server, ESEUTIL is located in the E:\Support\Utils folder of your Exchange 2000 CD (where E:\ is the drive letter of your CD-ROM drive).
If you are running Exchange Server 2003, ESEUTIL is located in the F:\Program Files\exchsrvr\bin directory after running Exchange Server 2003 Setup (where F:\ is the drive letter of the drive to which you installed Exchange Server).
You can only perform offline defragmentation when your Exchange Server databases are offline. Therefore, your e-mail users will not have access to mailbox data during the offline defragmentation processes.

During the offline defragmentation process, Eseutil.exe creates a new database, copies the old database records to the new one, and then discards unused pages, resulting in a new compact database file. To reduce the physical file size of the databases, you must perform an offline defragmentation in the following situations:

After performing a database repair (using Eseutil /p)
After moving a considerable amount of data from an Exchange Server database.
When an Exchange Server database is much larger than it should be.

Important:

You should consider an offline defragmentation only if many users are moved from an Exchange Server database or after a database repair. Performing offline defragmentation when it is not needed could result in decreased performance.
When using Eseutil.exe to defragment your Exchange Server databases, consider the following:

To rebuild the new defragmented database on an alternate location, run Eseutil.exe in defragmentation mode (using the command Eseutil /d) and include the /p switch. Including the additional /p switch during a defragmentation operation enables you to preserve your original defragmented database (in case you need to revert to this database). Using this switch also significantly reduces the amount of time it takes to defragment a database.


Because offline defragmentation alters the database pages completely, you should create new backups of Exchange Server 2003 databases immediately after offline defragmentation. If you use the Backup utility to perform your Exchange Server database backups, create new Normal backups of your Exchange Server databases. If you do not create new Normal backups, previous Incremental or Differential backups do not function because they reference database pages that were re-ordered by the defragmentation process.
For more information about defragmenting Exchange 2000 Server and Exchange Server 2003 databases, see the following articles in the Microsoft Knowledge Base:


  • Article 192185: How to Defragment with Eseutil Utility (Eseutil.exe)
  • Article 324672: Offline Defragmentation with Eseutil, webcast
  • Article 328804: How to Defragment Exchange Server Databases
  • http://www.microsoft.com/exchange/techinfo/tips/defragmentation.asp

Comments

Popular posts from this blog

Integration with vCloud Director failing after NSXT upgrade to 4.1.2.0 certificate expired

  Issue Clarification: after upgrade from 3.1.3 to 4.1.2.0 observed certificate to be expired related to various internal services.   Issue Verification: after Upgrade from 3.1.3 to 4.1.2.0 observed certificate to be expired related to various internal services.   Root Cause Identification: >>we confirmed the issue to be related to the below KB NSX alarms indicating certificates have expired or are expiring (94898)   Root Cause Justification:   There are two main factors that can contribute to this behaviour: NSX Managers have many certificates for internal services. In version NSX 3.2.1, Cluster Boot Manager (CBM) service certificates were incorrectly given a validity period of 825 days instead of 100 years. This was corrected to 100 years in NSX 3.2.3. However any environment originally installed on NSX 3.2.1 will have the internal CBM Corfu certs expire after 825 regardless of upgrade to the fixed version or not. On NSX-T 3.2.x interna...

Calculate how much data can be transferred in 24 hours based on link speed in data center

  In case you are planning for migration via DIA or IPVPN link and as example you have 200Mb stable speed so you could calculate using the below formula. (( 200Mb /8)x60x60x24) /1024/1024 = 2TB /per day In case you have different speed you could replace the 200Mb by any rate to calculate as example below. (( 5 00Mb /8)x60x60x24) /1024/1024 =  5.15TB  /per day So approximate each 100Mb would allow around 1TB per day.

Device expanded/shrank messages are reported in the VMkernel log for VMFS-5

    Symptoms A VMFS-5 datastore is no longer visible in vSphere 5 datastores view. A VMFS-5 datastore is no longer mounted in the vSphere 5 datastores view. In the  /var/log/vmkernel.log  file, you see an entry similar to: .. cpu1:44722)WARNING: LVM: 2884: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device shrank (actual size 18424453 blocks, stored size 18424507 blocks) A VMFS-5 datastore is mounted in the vSphere 5 datastores view, but in the  /var/log/vmkernel.log  file you see an entry similar to: .. cpu0:44828)LVM: 2891: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device expanded (actual size 18424506 blocks, stored size 18422953 blocks)   Purpose This article provides steps to correct the VMFS-5 partition table entry using  partedUtil . For more information see  Using the partedUtil command line utility on ESX and ESXi (1036609) .   Cause The device size discrepancy is caused by an incorrect ending sector for the VMFS-5 partition on the ...