Sponsored by Stellar Data Recovery
With every Exchange release, there are significant improvements and changes made to help IT and Exchange admins overcome limitations, ensure efficiency, and speed up the performance, along with new functionalities for the users in mobility. But before deploying Exchange server, it is critical to plan and know about the best industry practices for Exchange Server and mailbox database management. This will help you run the Exchange Server optimally, ensuring smooth workflow and business continuity.
In this guide, we will look at some of the best practices for managing Exchange Server databases.
Exchange Server database components
Before we move to the best practices, let us quickly look at the Exchange Server database components. In Microsoft Exchange, all related data is created and stored in an Exchange Server database. This Exchange database consists of the following files:
- .EDB or Exchange Server Database file: This file contains user mailboxes, Public Folders, and other data. The maximum supported size of the file is 1TB (Standard Edition) and 16TB (Enterprise Edition) in Exchange.
- .LOG files: Exchange Server maintains a set of transaction log files for the database that records all the operations (create, modify, delete mailboxes or messages) and changes performed on the Exchange server database. It also acts as a middleman between the database and the user’s access.
- .CHK or Checkpoint files: These files record details of transaction logs that have been committed to the database file. It helps to recover data from an inconsistent database due to system failure or database corruption.
Best practices for Exchange Server Database in standalone and high availability environments
Maintain Exchange database Size
The database size limit is 1TB in Exchange Server Standard edition and 16TB in Enterprise edition. However, it is recommended to keep the database size to a maximum of 2TB per database for Exchange High Availability (DAG/replicated) or 200GB per database for Standalone (non-replicated).
Although the limits exist, as per Microsoft recommendations, it is best to keep the database size smaller. This will help you keep the data under control, reduce backup and recovery time, and reduce downtime when you need to dismount the database temporarily for administrative tasks.
If you can distribute the mailboxes across multiple databases, this will help you avoid single-point failure and restore mailboxes or databases faster in the event of a failure. Thus, before deploying the Exchange Server, it is crucial to plan the number of mailboxes per database, for example, by floor, department, or business units.
Furthermore, you may also remove or delete unwanted mailboxes or mailbox data to reduce the database size. But do not forget to take a local backup before deleting any data from your Exchange Server database for historical data or references.
Manage Exchange database and logs
If you have configured a standalone Exchange Server, you should use two separate volumes to store the database and transaction logs. Also, do not store more than one database per volume and one log per volume, depending on their size. Following this practice ensures the performance of the data as you can split the load of transaction logs and database on two separate disks in two separate arrays on your SAN or server.
For high availability Exchange Server environment with two Exchange servers, you can store the database and logs on the same volume. However, you should not store more than two databases and logs on the same volume.
It is highly recommended to ensure a regular backup of the volumes on different physical disks in both standalone and high availability Exchange Server environments. This will help you restore data if a system failure occurs and to truncate the logs. In this case, it is important to make sure that your backup software is application-aware and compatible with your Exchange Server version. If in doubt, it is best to ask your backup vendor for assistance in the matter.
Optimize Exchange Server database
By optimizing the database through defragmentation, you can reclaim the empty space (white space), avoid database corruption, avoid abrupt database dismount, and improve response time.
Microsoft Exchange Server provides native utilities, such as Eseutil.exe (Extensible Storage Engine Utilities), for database optimization and recovery. It can be used to fix corrupt databases, check database integrity, and defrag them to reclaim any empty spaces. However, the utility works on offline database files, which means you need to dismount the database to run optimization tasks. Thus, it disrupts email flow and database availability. All the mailboxes stored in the database remain unavailable for a significant time, depending on the database size. You need to also take into consideration that when you repair a corrupt database by using the Eseutil, there is no guarantee that it will be successful.
TIP: You can create a new database and then move all the mailboxes from the old to the new Exchange database. This can help you achieve a similar result without causing extended downtime, but the database in question must be mounted.
However, in the event of a disaster, such as a server failure or severe database corruption, you can use a third-party Exchange recovery tool, such as Stellar Repair for Exchange, to quickly recover and restore the data. The software can help you restore mailboxes from a damaged server or database directly to a live Exchange Server database in the same organization and significantly minimize the downtime and recovery time.
NOTE: Disk defragmentation is neither required nor recommended for mailbox servers.
Storage management
Transaction logs are highly critical to keep the Exchange database healthy. If uncommitted transaction logs are missing or accidentally deleted, it can lead to an inconsistent and dismounted database. Based on the emails sent or received by each mailbox, transaction logs can eat up a lot of disk space. For instance, if there are 500 mailboxes in a database and each mailbox sends or receives 75 messages every day, the mailbox can generate 15 transaction logs/day. This means 500×15=7,500 transaction logs per day per database. Additionally, when mailboxes are moved, they generate enough logs to fill up the disk volume.
To avoid issues, such as database dismount and downtime caused by insufficient storage space on transaction log volume, it is critical to truncate logs that are committed to the database. For this, you may enable circular logging or take regular full server backups to purge log files.
Further, as emails are heavily used to share data, mailboxes often grow quite large and require more storage. Although large mailboxes can be stored in the Exchange database without any issues, it is critical to restrict the mailbox growth by applying Mailbox Quota Limits. This will help prevent mailbox growth beyond capacity. It will also help perform the administrative and management tasks, such as mailbox backup, migration, and recovery.
Install and setup antivirus/malware protection
An Exchange antivirus software can help protect systems and data from malicious files and attacks. You may install and run antivirus software on your Exchange server for spam filtering, protection against phishing mail attacks, malware attachments, etc. However, you should set up antivirus or antimalware protection carefully. To avoid transaction log file corruption and dismount issue, it is important to exclude specific files, paths, and processes from antivirus scans.
If an antivirus is not configured correctly, it can lock files or folders during the scan that can affect the Exchange Server performance and operations, leading to failure or unexpected database dismount.
Conclusion
By following the Exchange Server database best practices discussed in this post, you can ensure efficient server performance and avoid unnecessary Exchange Server database issues, such as unexpected dismount or corruption. However, if the database gets corrupt or damaged and does not mount due to corrupt or missing logs, you can use a third-party Exchange recovery application, such as Stellar Repair for Exchange. It can repair damaged EDB files, extract mailboxes, save them to PST or export them directly to the live Exchange server database, and minimize the downtime while recovering Exchange mailboxes.
Featured image: Shutterstock
