DBMIRROR_DBM_MUTEX: The world of Redo Operations

This post has been republished via RSS; it originally appeared at: SQL Server Support articles.

First published on MSDN on May 26, 2017
There are times when you just run into something and you can deem less important and continue. And there are times, where you have to stop and deal with it. In the past few weeks this wait type has simply come up way too many times.

First, there is a great empirical blog post by Joe Sack on this and other Database Mirroring (DBM) wait types. So you may start there.

Here are some points on the DBMIRROR_DBM_MUTEX wait type:

1. This wait type is used in the Redo logic in Database Mirroring. That is, as Joe Sack observed empirically, all this happens on the Mirror/replica server. Therefore, if it were up to me, I would rename this wait type to DBMIRROR_DBM_ REDO . "Redoing" log records means applying to the Mirror what was sent by the Principal. Here is some more information on this topic :
"The principal server continues to make the principal database available to clients and client connections.
After mirroring starts, each time a client updates the principal database, on writing the transaction to the log
of the principal database, the principal server also sends that log record to the mirror server. There, the mirror
server immediately writes the log record to disk as the last record in the redo queue.

In the background, beginning with the oldest log record, the mirror server redoes the log on the mirror database,
record by record, as quickly as possible. Redoing the log involves applying the queued log records to the mirror
database in sequence, starting with the oldest record. Each log record is redone once and only once. As the mirror
server redoes the log, the mirror database is continually rolled forward. When the principal server truncates or
shrinks the log for the principal database, the mirror server also shrinks the log at the same point in the
log stream"
2. This wait type seems to be used for all things wait-related inside of the Redo Manager:

Operation Waiting for work
Wait for a redo thread to exit since it has no work to process ...to be available (idle)
Wait for any redo work to be given to the Mirror - idle state ...to be available (idle)
Wait for one or all parallel redo operations (performed by multiple redo threads, in parallel) to complete ...to complete (busy)
Wait for redo segments to be completed ...to complete (busy)
Wait for a rollback thread to complete after an DBM failover ...to complete (busy)




One would argue that this is not the best use for a single Wait type; that perhaps there should be at least 2 wait types here - one for busy threads and one for idle threads. And one would be right to argue that...

Summary: DBMIRROR_DBM_MUTEX wait type is used to indicate waits in the REDO manager on the Mirroring server.  These are waits for either busy threads to complete their redo work or for idle threads to pick up new redo work. How's that helpful? It's for you to decide.

Namaste,

Joseph

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.