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.
DBMIRROR_EVENTS_QUEUE is background noise on a healthy instance. If you are chasing a real problem, start with the waits that actually cost you time.
- The waits that usually matter, ranked, with what each one is telling you.
- HADR_SYNC_COMMIT Wait Type, the closest wait worth investigating when this one is high.
- High Availability, the scripts and guides for this part of the stack.
Leave a Reply