DBMIRROR_DBM_MUTEX is a database mirroring wait that occurs only on the mirror server, when a thread waits for parallel threads that are replaying (redoing) log records on the mirror database. It is synchronisation inside the mirror’s redo machinery, the threads coordinating who applies what.
If you see it on an instance, that instance is acting as a mirror for at least one database.
Is It a Problem?
Rarely. It has not been a noticeable contention point in practice; it is bookkeeping between redo threads doing their normal job. Because the mirror typically runs little other workload, mirroring waits can look large in its wait profile simply because there is nothing else competing for the top spots.
The genuine thing to watch on a mirror is not this mutex but the redo queue: whether the mirror is applying log as fast as it arrives. A mirror that falls behind extends failover time, because outstanding redo must finish before the mirror can come online as principal.
Common Causes
- Normal parallel redo activity on the mirror while log records are replayed.
- Heavy log bursts from the principal (index maintenance, bulk loads) giving the redo threads more coordinating to do.
What To Do
- Check the redo queue on the mirror via the mirroring performance counters (SQL Server:Database Mirroring, Redo Queue KB and Redo Bytes/sec). A stable, small queue means all is well.
- If redo lags, look at the mirror’s hardware: log disk latency and CPU headroom, since redo competes with whatever else the server runs.
- Do not chase the mutex wait itself; there is no knob for it. Fix redo throughput and it fades into the background.
- If you are still sizing mirrors casually, remember the failover cost: a mirror that keeps up fails over in seconds.
How To See It
Rank it against everything else with Get-WaitStatistics on the mirror server, and read it alongside the redo queue counters rather than in isolation.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply