Log Reuse Waits Explained: DATABASE_MIRRORING

Introduction

There are eight reasons SQL Server might report when it cannot truncate the transaction log. Any one of these reasons results in a growing log file. This short series is looking at each of them in detail, explaining what is causing it and what you can do to resolve it. Today's log reuse wait reason is: DATABASE_MIRRORING

Database Mirroring

Database mirroring is deprecated since SQL Server 2012. So this wait type will go away at some point. But for now there are still quite a few installations out there. Therefore I decided to cover it anyway.

Database mirroring allows you to have a second exact copy of your database on a different server. There are two operating modes: high performance and high-safety. In high-safety mode a transaction can only be committed if it has been applied to both databases. This can cause higher transaction latency but you will not lose any data if one of the two servers suddenly dies.

In high-performance mode on the other hand, transactions are committed on the primary server first and then transferred over to the secondary server. That reduces the latency impact on the primary server, but you might run the risk of some data loss if the secondary is behind at the time the primary server goes down.

Waiting for the Secondary

If you set database mirroring up in high-performance mode, a background process reads records for committed transaction from the transaction log and then sends enough information over to the secondary to repeat the action that transaction executed.

If the secondary falls behind, for example because of an interrupted network connection, the log reading process will wait until it can continue to transmit transaction information. During that time, transactions in the log that have not been processed by the mirroring agent cannot be purged and the virtual log files containing these records can't be reused. SQL Server will return a log_reuse_wait_desc value of DATABASE MIRRORING if it runs out of virtual log files because of this.

To solve this issue make sure the server housing the database mirror is adequately sized to keep up with the transaction load and the network connection between the two is stable. Also make sure there is enough room for the transaction log of the source database to grow in case of a mirror delay.

Summary

SQL Server database mirroring is a deprecated high availability solution. It allows us to have copy of a database on a secondary server that is automatically kept in synch, either synchronously or asynchronously. In high-performance mode, the transaction log information of committed transactions is used to apply the changes asynchronously to the secondary. A log_reuse_wait_desc value of DATABASE MIRRORING indicates that this process is falling behind and can't process log records quickly enough.

The high-safety mode on the other hand applies all changes synchronously and therefore has no impact on transaction log reuse.

Log Reuse Wait Series

This post is part of a short series about circumstances that prevent transaction log truncation.
Below is a list of links to the posts that are already available.