How to defrag exchange 2010 database [Step By Step Guide with Screens]

Why do we need to defrag the exchange mailbox database? Here are some situations in which you have to perform defragmentation on your exchange mailbox database:

1. No additional space left to create a new database to migrate the mailbox.
2. Active alerts for the low disk space.
3. In order to claim whitespace created by archiving process.

Your options to reclaim space (whitespace) created due to deletion of mails and other items from mailbox are to either:

• Create a new mailbox database and move all the mailboxes to that database: A mailbox migration has fewer risks, can be less disruptive as a whole, but will generate a lot of transaction logging that needs to be kept under control so it may take longer (i.e. several nights/weekends to migrate) as opposed to just one outage for a defrag.
• Perform an offline defrag (using eseutil /d command): An offline defrag involves an outage for all users on that database, but may be more convenient if there is not additional storage available to allocate to the Exchange server to hold the new database.

Defrag exchange 2010 database using eseutli /d (Step by Step Guide)

Note:

• You can defragment a database only if it is dismounted which means no user can access the database (emails) until the defrag process is complete.
• You need some available disk space (1.2 times free space) to perform the defrag. This is because a new file is written during the defragmentation process. 
• Most important one the backup that you can use for recovery if something goes wrong during the defrag. 

Here the steps that you can follow to perform defragmentation exchange 2010 database:

Step 1: Check the size of mailbox (how big it is?) and how much whitespace is there. To check this you need to run the following command in Exchange Management Shell.

[PS] C:\>Get-MailboxDatabase -Status | ft name,databasesize,availablenewmailboxspace –auto

This command will show Name, Size and Available New Mailbox Space (whitespace). The whitespace is created due to             archiving. If you want to reclaim this space go to step 2.

Step 2: Open the Exchange Management Shell and navigate to the folder containing the database file.

cd D:\Data\MB-HO-01

Step 3: Dismount the mailbox database.

Dismount-Database MB-HO-01

Step 4: Run ESEUtil to defrag the file.

[PS] D:\Data\MB-HO-01>eseutil /d MB-HO-01.edb /t\\testserver\defrag\temp.edb

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.

Step 5: Mount the database again.

mount-Database MB-HO-01

Step 6: check that the file is smaller, and all the white space is gone.

Get-MailboxDatabase -Status | ft name,databasesize,availablenewmailboxspace -auto

Reasons why not to do offline defrag

Here are the top reasons why you should not perform offline defrag using Eseutil /d unless or until it is very necessary:

1. Database Dismounted during the defrag process: During the defragmentation process as stated above you need to dismount the database first. Dismounting the database for a long time can cause problem (emails can’t be accessed). After the defragmentation process complete you need to remount the database and take a full backup immediately which is time consuming.
2. Risk of Database Corruption: There is risk of database corruption during the defrag process.
3. Complicated and time consuming: offline defrag not only complicates the process of backup and recovery but also a time consuming process. 

So what’s the alternative for offline defrag process?

So what to do in case of getting active alerts for low space on storage (database need to be cleared) otherwise database dismounting problem.

Read the following post for better solution to increase the size of database and other life saving strategies that you can perform in order to save you exchange database from being corruption. 

Read More

Exchange Database Exceeds Size limit Problem and Solution

Error: Database size has exceeded the size limit of

Product: Microsoft Exchange Server

Error Message: [Event ID 9690]

Exchange store '<storage group name>': The logical size of this database (the logical size equals the physical size of the .edb file and the .stm file minus the logical free space in each) is <number> GB. This database size has exceeded the size limit of <number> GB.This database will be dismounted immediately.

Problem Cause

The above error message comes when the logical size of the database becomes greater than the one that you configured.  

The logical size of the database is calculated by adding the physical size of EDB and STM files minus the logical free space in them.

Default Size Limit of Exchange Server 

Exchange Server 2003 Database Size Limit

In Microsoft Exchange 2003, Standard Edition supported two databases in single storage group (one for mailbox and other for public folder database). The standard edition before SP2 of Exchange Server 2003 have 16 GB database size limit for each database which cannot be configured further. However with SP2 Edition you get 18 GB default configuration limit which is 2GB extra with a maximum size limit of 75 GB, which means you can increase the limit by upto 75 GB by using a registry key.

The enterprise edition of Exchange Server 2003 gives 8,000 GB (actually it depends on the hardware of the system) size limit for each database. 

Database Size Limit in Exchange Server 2007 and later version (2010 and 2013).

Exchange Server 2007 standard edition RTM supported five databases and up to five storage group (instead of just two databases which is the case of in Exchange Server 2003 edition). The default size limit is 50GB per database which can be increase up to 15 TB by editing registry values. In Exchange 2007 Standard Edition SP1 the limit is 250GB. There is no default database size limit for the Exchange 2007 Enterprise Edition.

In standard edition of Exchange Server 2010 the default size limit is 1024 GB (i.e 1 TB) and there is no default size limit for Enterprise edition users.

In Exchange Server 2013 we got maximum limit of 16TB although it recommended to use 2 TB size limit for database because the larger the size of Database, larger the time taken to take backup and recovery process.

What will happen if the configured or licensed database size limit reached?

As soon as the database mounts in Exchange Server the following process will happen

1. The store process compares the Physical Database size with the Configured Database Size Limit.If the physical size is within or exceeds the configured Database Size Warning Buffer in Percentage, the store performs a logical calculation of the database size.
2. If it is below this warning buffer, there is no need to calculate the free space because the logical size will never exceed the physical size. 

With Exchange Server 2003 SP2 or later, the server performs the following tasks when the configurable (or default configured) database size limit is reached:

• If the first check after a database mount finds the database size above the limit, the database will not be taken offline but an error event (ID 9689) will be logged in the Application event log.
• If it is the second check, an error event will be logged in the Application event log and the database will be taken offline. 

So what’s the solution to the problem stated above? Offline Defragmentation! No, you will need at least 1.5 times the database size in available hard drive space to run it. Below are the best possible solutions for the problem of Database size exceeded size limit.

Solution 

Method 1: Increase the configured size limit of Exchange Database using Registry

Note: Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system.

Step 1: Open Regedit and browse to the following registry key: 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-<database GUID> 

Step 2: If the key “Database Size Limit in GB” DWORD already exists under the subkey “Private-[database GUID]”, change its value to the desired size in gigabytes, be sure to select ‘decimal’ when you enter the number.

If the “Database Size Limit in GB” DWORD does not exist for the subkey then create a new DWORD “Database Size Limit in GB”, and then set its decimal value to the desired size in gigabytes.

Note: You may need to restart the information store service for the changes to take effect.

Step 3: Restart the Microsoft Exchange Information Store service

Step 4: Check event viewer for the following events:

Event ID 1216 will provide information about what is the current physical size of the database and how much size is allocated.

Method 2: Reduce the size of database or create a new database.

You can reduce the database size by creating a new database and move the files into it. Or you can ask users to delete mailbox or public folder data that is not required. But deleting mails will not create free space most of the time and it is better to create a new database and move some data into it. Moving mailboxes from one Exchange Database to another cleans corrupt items and will boost the performance. After moving the database makes sure you update your backup scheme to include the newly created second database. One more benefit of creating a new database is it allows you to keep your store up and the mail flows.

What if the problem still exists?

What if the above two solutions failed to work and you still get the error “This database will be dismounted immediately.” So it is recommended to convert the edb files of the Exchange Server into PST file which can done by EDB to PST Converter easily even if there is size, corruption or dismounting database issues.

By converting EDB file (priv.edb and pub.edb) into PST file format user can get rid of the problem of edb size and dismounting issues.

Read More