This is the third part of a four part series that addresses database management in an Exchange 2010 environment. It is meant to provide a good overall introduction into the maintenance and monitoring needed to ensure the health of your Exchange 2010 databases.
One of the first things we want to be sure to configure is online maintenance settings. Two of the things we can configure here are the maintenance window and how we can checksum for corruption. In Exchange 2010 online defrag runs in the background but online maintenance can be scheduled to run during a specific maintenance window. You can set the maintenance window as seen below.
Configuring Online Maintenance Windows
Set-MailboxDatabase EXDB01 –MaintenanceSchedule “Sun.1:00 AM-Sun.3:00 AM”
In the case of smaller databases we can also specify database checksumming to run during online maintenance. This will check for corruption.
Set-MailboxDatabase EXDB01 –BackgroundDatabaseMaintenance $False
Server Maintenance
In the case that you need to perform overall server maintenance (for example, hotfixes or Windows updates) and your server is a member of a Database Availability Group you will need to prepare the server for maintenance. This isn’t necessarily database maintenance specific but these commands are needed to ensure the health of your overall DAG from a server database copy perspective. Fortunately Microsoft has made this really easy and included Powershell scripts that you can run to ready the server.
StartDagServerMaintenance.ps1
This script will move all active database copies off of the server and set the DatabaseCopyAutoActivationPolicy to block databases from moving to that server. Running this will also make sure all critical DAG support functionality hosted by the server is moved as well and blocked from moving back to the server.
StopDagServerMaintenance.ps1
This script will complete the maintenance operations removing the blocks put in and allow the server to resume normal function as any other member of the DAG.
Database Whitespace
Simply put database whitespace is the empty space in a database file which is counted as used space on a disk. In normal operations the physical size of an Exchange database grows as data is added to it. When data is removed the amount of data contained in the database is les, but the physical database size on the disk does not shrink. As a result the database itself will always have free pages, or white space, spread throughout. During background database maintenance, items marked for removal from the database are removed, which frees these pages. The percentage of white space is constantly changing due to the efforts of the 24×7 online defragmentation process. In the past you could view Event ID 1221 (below) to get an idea of whitespace for a particular database. However in Exchange 2010 there is no longer a 1221 event ID, this is because whitespace is constantly changing due to 24×7 online maintenance.
In Exchange 2010 we can run the below management shell command to determine available whitespace.
Get-MailboxDatabase -Status | Select-Object Server,Name,AvailableNewMailboxSpace
To specify an individual Database you can run the following command
Get-MailboxDatabase EXCHVIP -Status | FL AvailableNewMailboxSpace
If you would like to monitor the status and performance of online defragmentation Microsoft Exchange includes the counters below.
| MSExchange Database Instances \ Defragmentation tasks | Shows the background database defragmentation tasks currently executing. |
| MSExchange Database\ Defragmentation Tasks completed/Sec | Shows the number of background database defragmentation tasks completing execution per second. |
| MSExchange Database\ Defragmentation Tasks Discarded | Shows the background database defragmentation tasks that couldn’t be registered. |
| MSExchange Database\ Defragmentation Tasks Pending | Shows the background database defragmentation tasks currently pending. |
Additionally if you run into problems with a particular Exchange 2010 database, say maintenance isn’t working as expected or perhaps backups are failing, you can simply create a new database and move mailboxes to the new data store. This will minimize downtime and user impact while giving administrators the peace of mind of a clean new database. In previous versions of Exchange you needed to perform an offline defragmentation with ESEUTIL /D, this required a significant amount of downtime and was subject to frequent errors. In Exchange 2010 you can move mailboxes easily, and in the case of corruption only the offending mailboxes will be impacted.
Hopefully we’ve provided a good introduction to Exchange 2010 database maintenance. Please check back next week for part 4 where I show how GSX can help with database management in Exchange 2010.
GSX Solutions is the leading provider of monitoring and reporting solutions for Unified Communications applications, whether on-premises or in the cloud. Find out more now >>
GSX Solutions provides the only Office 365 user experience monitoring tool that truly measures the quality of the service delivered to all enterprises’ sites, enabling their IT to take power of the Office 365 performance.
Get started today with Office 365 monitoring and see how you can keep your employees on the path to optimal productivity.
