DBMIRROR_EVENTS_QUEUE is recorded by the main database mirroring thread while it waits for events to process. It only exists where database mirroring is configured, and on a quiet principal the individual waits can run very long, because there is simply nothing for the mirroring machinery to react to.
The mirroring engine’s front desk, waiting for the phone to ring.
Is It a Problem?
No; it is a benign idle wait that belongs on the filter list. Its totals track mirroring being configured and the workload being quiet, neither of which needs fixing. On estates still running mirroring (deprecated but persistent), it pads raw wait rankings without meaning.
Actual mirroring performance lives elsewhere: the send queue and transaction delay counters, DBMIRROR_SEND when the network backs up, and redo queue on the mirror.
Common Causes
- Database mirroring configured, with the event thread idling between happenings.
- Quiet periods on the principal.
What To Do
- Filter it out; it carries no signal.
- For mirroring health, watch the SQL Server:Database Mirroring performance counters and
DBMIRROR_SEND. - Longer term, plan the migration to Availability Groups; mirroring has been deprecated for years.
How To See It
Rank waits with Get-WaitStatistics, where it is treated as background noise on mirrored instances.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply