TL;DR — Résumé Rapide

Microsoft Exchange Server is a mail server and calendaring server developed by Microsoft, used for enterprise email, calendar, contacts, and task management.

Note : Cet article a été publié à l’origine en 2013. Certains étapes, commandes ou versions de logiciels ont pu changer. Consultez la documentation actuelle de Exchange pour les informations les plus récentes.

Prérequis

Avant de commencer, assurez-vous d’avoir :

  • Exchange Server installed and configured
  • Administrative access to Exchange Management Console/Shell
  • Active Directory environment

How to: Compact the size of an Exchange Mailbox Database

As of late I have been working on moving mailboxes form an onPremise deployment to the cloud in a hybrid environment. As I made progress I noticed the servers that hosted the Mailbox databases were using a lot of hard drive space and that backups were huge. Even after moving the mailboxes over to the cloud the space was not returned to the OS. This made me wonder, what really is going on with an Exchange Database. After doing some reading around the first thing I found was that Exchange logs every transaction and is able to reconstruct the entire database out of those logs. This roughly means you are storing about twice the amount of information that what you actually have. You can either use a backup application that clears those logs or enable circular logging. If you want to learn more about that there is an article titled: (/circular-logging-microsoft-exchange-server/ “What is: Circular Logging in Microsoft Exchange Server”).

So, at this point the first thing to do is address the issue around not cleaning up the (https://en.wikipedia.org/wiki/Transaction_log “Transaction log”) files. But then you realize that the database even though its mailboxes are using a few megabytes of data has a size in the gigabytes. What happens is the Exchange mailbox database is sort of like a (https://www.iso.org/iso/catalogue_detail.htm?csnumber=45498 “SQL”), it grows in size, reserves more space from the hard drive… but unlike SQL there is no way to schedule a maintenance job to shrink the database. I guess this makes sense… an email database ought to grow 99% of the time. Even if a user starts purging their emails there are others and that space will be used again shortly in general. The solution to this lies in running a utility to defragment the database and therefore release the space that is not in use back to the OS. Now, as I pointed out there is no reason to do this generally. In my particular case as I moved gigabytes worth of data to another database that space is not going to get used any time soon in the foreseable future. The issue here is that in order to defragment the database you need to bring it offline and that will have an impact on the users whose mailboxes are stored in that db.

So in summary:

  1. Be sure to use a Microsoft Exchange compatible backup utility so that your database logs are cleared frequently. If you have another solution in place you might want to look into circular logging.
  2. Use eseutil -d “Mailbox Database 1.edb” to defragment your database after a large purging of emails. Remember that it has to be offline for this to work
  3. Transfer your mailboxes to another database and delete the source one once done. Remember there might be Archive, System and other kind of mailboxes besides user ones.

In order to use eseutil here is the information regarding syntax for the defragmentation of the db:

(https://en.wikipedia.org/wiki/Extensible_Storage_Engine “Extensible Storage Engine”) Utilities for Microsoft(R) Exchange Server Version 15.00 Copyright (C) (<https://maps.google.com/maps?ll=47.6395972222,-122.12845&spn=0.01,0.01&q=47.6395972222,-122.12845 (Microsoft)&t=h> “Microsoft”). All Rights Reserved. DESCRIPTION: Database utilities for the Extensible Storage Engine for Microsoft(R) Exchange Server. MODES OF OPERATION: Defragmentation: /d Recovery: /r Integrity: /g Checksum: /k Repair: /p File Dump: /m Copy File: /y Restore: /c <<<<< Press a key for more help >>>>> D=Defragmentation, R=Recovery, G=inteGrity, K=(https://en.wikipedia.org/wiki/Checksum “Checksum”), P=rePair, M=file duMp, Y=copY file, C=restore => (https://en.wikipedia.org/wiki/Defragmentation “Defragmentation”)/COMPACTION: DESCRIPTION: Performs off-line compaction of a database. SYNTAX: /d PARAMETERS: - filename of database to compact OPTIONS: zero or more of the following switches, separated by a space: /t - set temp. database name (default: TEMPDFRG*.EDB) /p - preserve temporary database (ie. don’t instate) /b - make backup copy under the specified name /2 - set 2k database page size (default: auto-detect) /4 - set 4k database page size (default: auto-detect) /8 - set 8k database page size (default: auto-detect) /16 - set 16k database page size (default: auto-detect) /32 - set 32k database page size (default: auto-detect) /v - verbose output /o - suppress logo NOTES: 1) If instating is disabled (ie. /p), the original database is preserved uncompacted, and the temporary database will contain the defragmented version of the database.

Below is a sample execution of the eseutil command to defragment and offline database:

E:Exchange DBs>eseutil -d “Mailbox Database 1.edb” Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Version 15.00 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating DEFRAGMENTATION mode… Database: Mailbox Database 1.edb Defragmentation Status (% complete) 0 10 20 30 40 50 60 70 80 90 100 |----|----|----|----|----|----|----|----|----|----| … Moving ’.TEMPDFRG6624.EDB’ to ‘Mailbox Database 1.edb’… DONE! Note : It is recommended that you immediately perform a full backup of this database. If you restore a backup made before the defragmentation, the database will be rolled back to the state it was in at the time of that backup. Operation completed successfully in 97.625 seconds.

Résumé

Articles Connexes