Grafvision - Fotolia

Problem solve Get help with specific problems with your technologies, process and projects.

How database availability groups have improved in Exchange 2013

Exchange 2013 database availability groups have improved significantly since Exchange 2010. These four updates are worth investigating.

Each new version of Exchange brings advances and improvements, and Exchange 2013 is no different. While many advances...

are clear -- think new features -- others are not as obvious. For example, updated database availability groups don't necessarily stand out, but they've been upgraded substantially in Exchange 2013 and will prove extremely beneficial to customers. Let's examine the four major areas where DAGs have improved.

The Managed Store

More on Exchange 2013

Highlighting PowerShell changes for Exchange 2013 public folders

Explaining client access server role changes in Exchange 2013

Exploring the Exchange Administration Center in Exchange 2013

One of the biggest changes Microsoft made to Exchange 2013 database availability groups (DAGs) is that the Information Store (store.exe) has been completely rewritten. It now uses managed code written in C#. The new Managed Store provides a separate, dedicated worker process for each database. If there is a problem with a database, it should not affect other databases running on the server because they are managed by their own unique worker processes.

Lagged database copies

Activating a lagged database copy in Exchange 2010 is a major undertaking, so Microsoft simplified the process in Exchange Server 2013. This simplification largely revolves around a new Exchange 2013 feature called Safety Net.

An admin typically uses a lagged database copy to recover from database corruption. When corruption occurs within a database, it can spread to any passive copies of the database within the DAG. A lagged copy lets you restore the database to an earlier point in time before the corruption occurred.

The problem with lagged copies in Exchange 2010 is that you must know exactly when the corruption occurred in order to purge the log files that accumulated after the point of corruption. This operation unfortunately results in data loss.

The new Exchange 2013 Safety Net is a delivery queue that exists on each mailbox server. Each time a message is successfully delivered to the mailbox database, a copy of the message is placed in the Safety Net. The message remains there until it reaches its expiration period. The default expiration period is two days.

Safety Net not only makes activating a lagged copy easier, but also helps reduce data loss. For example, let's assume you need to activate a lagged database copy with a two-day lag. In this situation, you would normally suspend the replication process, then purge all the log files, except for those that fell within the time period before the corruption occurred.

When you try to mount a copy of the lagged database, Exchange 2013 is smart enough to know that you may not have all the log files. Exchange 2013 then extracts the missing data from the Safety Net, greatly reducing the amount of data lost. The potential amount of data loss here is comparable to a lossy failover.

Automatic reseeding

One of the most publicized new Exchange 2013 database availability group features is the automatic reseed. In Exchange Server 2010, a database reseed had to be manually initiated by an administrator if he discovered that a database copy had been corrupted or impacted by disk failure.

In Exchange 2013, the automatic reseed feature takes action automatically to preserve redundancy when disk failures occur. Upon detecting a disk failure, Exchange 2013 can perform an automatic reseed by replicating the contents of another database copy to a spare disk. Note that this takes advanced planning, as you must designate a disk to function as a spare.

Multiple databases on a single volume

Microsoft made a number of storage-related improvements in Exchange Server 2013. Among them is added support for disks of up to 8 terabytes in size.

More on database availability groups

Making the most of Exchange 2010 DAGs

How to update an Exchange 2010 database availability group

Examining multisite DAGs

On the surface, it appears that large disk support is useful for accommodating large databases. The problem here is that when Exchange Server databases grow beyond a reasonable size, they become difficult to manage. This is particularly true when it comes to backup and restoration operations.

The primary benefit to Exchange 2013's large disk support is that you can now store multiple database copies on a single disk. A disk can accommodate one active database copy and a number of passive database copies.

Previously, the I/O load generated by the database copies made it impractical to store a mixture of active and passive database copies on a disk -- even if the software had allowed it. Because Microsoft made numerous architectural changes to the database structure, these changes have driven down disk I/O to the point where it's now practical for a single disk to host multiple database copies.

About the author
Brien Posey is a ten-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a chief information officer at a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the nation's largest insurance companies and for the Department of Defense at Fort Knox.

Dig Deeper on Exchange Server setup and troubleshooting