How to Reduce EDB File Size in Exchange Server?

Microsoft recommends that the size of the EDB file in a standalone Exchange Server should be 200 gigabytes (GB) or less, and for a high-availability server, the size can go up to 2 terabytes (TB) or less. When database size crosses the recommended limit, the server lags and normal day-to-day tasks become difficult to complete.

Therefore, Exchange administrators recommend strictly maintaining the EDB file under a healthy limit. For that, they often manually reduce Exchange EDB file size. In the following sections, we will discuss different methods to safely reduce EDB file size. But before that, let's see why it is important to reduce the database size and what happens if it crosses the default threshold size limit.

Why Should You Reduce Exchange EDB File Size?

In addition to fixing the database dismounting issues, Exchange administrators reduce EDB file size because:

• An Exchange Server running a lean database provides faster performance than a server with an oversized EDB file.
• Faster backup and data restore. For example, backing up a 200 GB EDB file is faster than 1 TB database.
• Periodically taking measures to reduce Exchange database size ensures services like Information Store and others continue to run without errors.
• Mailbox management and migration are easy when you maintain the recommended EDB size limit.
• Small databases are less likely to get a JET engine error due to abrupt server shutdown, preventing page-level corruption.

Common Problems with Large EDB Files

For a standard edition of Exchange Server, the default size limit is 1024 GB, but Microsoft still recommends keeping the database at approximately 200 GB or less. This is because of:

• Server performance degradation: The oversized EDB will put strain on the storage, as the larger the database, it demands more I/O operations. This will affect the Exchange Server at boot time and other operations, leading to slow server performance.
• Abrupt database dismount: When the EDB file size keeps on increasing and fills the database to 100% of its capacity, the Information Store service will dismount the .edb file. It will affect the whole organization, as all email-related work will be halted until you reduce EDB database size in Exchange Server.
• Delay in Searches: It is difficult to search the mailbox items in a large EDB file. Indexing all the mailbox items in an oversized database requires heavy resource usage. This, in turn, leads to slow indexing and searching.
• Corruption in database: When the EDB file size is too large, the database crashes several times. Multiple sudden crashes lead to EDB file corruption. To fix this, the administrator must repair corrupt Exchange database.

How to Reduce Exchange EDB File Size?

An oversized EDB file is a challenging issue. Luckily, there are many ways to reduce EDB file size in Exchange Server. Some are discussed here:

Method 1: Delete Unnecessary Mailbox Data

It is one of the most obvious methods to effectively reduce Exchange database size. Deleting unwanted data will create more free space for adding new data. But make sure you don’t end up erasing important data accidentally, which is why it is important to back up the whole Exchange database before you make the move.

However, it may happen that even after deletion, you do not see any reduction in the size of the EDB file. But don’t worry—the space created by deleting the data is there and Exchange will use it whenever users are adding new data (instead of increasing the database size).

Method 2: Move Mailboxes to Another Database

If you have another database with empty space, you can use it to free up space on the large database by moving mailboxes. Additionally, you can also create a new database to move the data from the oversized EDB.

There are two ways to move mailboxes to a different database in Exchange Server.

1. Using the Exchange Admin Center (EAC): In EAC, go to “Recipients” > “migration”. Click the “+” icon and select “Move to a different database”. Then, select the mailboxes to move, configure, and start the migration.
2. Using the Exchange Management Shell (EMS): Open the Exchange Management Shell and connect to the Exchange Server. After that, run the following command:

New-MoveRequest -Identity “user_mailbox” -TargetDatabase “db_name”

Moving multiple mailboxes together with the EMS is complex. Therefore, to move mailboxes in bulk, prefer either EAC or a professional Exchange migration tool. After the migration, the source mailboxes will be put into a soft-deleted state and will be purged from the EDB file after 30 days. However, even after moving the mailboxes, the database will not show free space. For that, you have to defragment it.

Method 3: Use ESEUTIL to Defragment the EDB File

When you delete or move a mailbox, the database size does not shrink immediately. Instead, Exchange leaves the free space as empty blocks to be taken automatically by new data in future. These empty blocks are called whitespace and Exchange administrators often manually remove the whitespace to reduce EDB database size using the eseutil tool.

Note: This method also allows you to reduce Exchange database size in the event when your server has dismounted the database due to large EDB size.

You can get the amount of whitespace in a database by running the following cmdlets in Exchange Management Shell:

Get-MailboxDatabase -Status | Format-List Name, DatabaseSize, AvailableNewMailboxSpace –Auto

Before starting defragmentation, ensure that you have enough free space (110% of the size of the database) available on the server (or the network). Now, stop the Exchange Information Store service, and follow the procedure below to perform the defragmentation:

1. In the Exchange Management Shell, navigate to the location of the database file.
2. Dismount the Exchange database for which the defragmentation is to be done:
   

   Dismount –Database <Database Name>

3. Perform defragmentation by running:
   

   Eseutil /d "<database location\DatabaseName.edb>" /t "<a temporary location\TempDatabaseName.edb>"

4. Mount the database again
   

   Mount –Database <Database Name>

5. After the completion of the defragmentation process, start the Information Store service.
6. Check if the database has been mounted, and then verify if all the Exchange services are working correctly.
7. Finally, run the command to check whitespace in the database to know the success of the defragmentation.

Remember: The speed of defragmenting an EDB using eseutil utility is usually 9 GB/hour and may vary according to the hardware and system environment.

What To Do If Eseutil Fails?

If your Exchange Server dismounts the database, it does not necessarily mean that a large EDB file was the culprit. A structural issue or corruption can also force the server to dismount the EDB file to prevent further damage.

Also, if eseutil tool fails to defragment the EDB file, it further supports the chances of a corrupt EDB file. In this situation, your priority should not be to reduce Exchange EDB file size. It should be to repair EDB files and restore user mailboxes.

You can use eseutil to fix corruption in the EDB file. However, the eseutil only helps with minor issues. If the EDB is severely damaged, eseutil will fail. In such a case, focus on recovering user mailboxes using an Exchange database recovery tool like Kernel for Exchange Server.

Reduce EDB File Size for a Healthier Exchange Environment

Set reminders to periodically check and analyze the Exchange database size. Make sure it never reaches 100% of its capacity, or it will be dismounted, causing downtime. Use the methods we discussed above to reduce Exchange database size and keep your Exchange Server running without errors.

If Exchange Server has dismounted the EDB file, do not immediately start with defragmentation. Check the state of the EDB file and verify if there is any logical or physical data corruption. If the EDB file is in a healthy state, defragment it and mount it on the server. If the database shows signs of corruption, repair it, then defragment it and mount it.

• Download Free
• Buy Now

Sarthak PoswalTechnical Writer

This article is written by Sarthak Poswal, a technical content writer at Kernel Data Recovery. This content has been reviewed in accordance with our editorial guidelines.