DBMIRROR_WORKER_QUEUE is recorded when a database mirroring worker task waits for more work to be assigned. Mirroring keeps a small crew of workers per session, and when the mirrored database is quiet, generating no log to ship or apply, the workers idle in this wait, sometimes for very long stretches.
The mirroring worker pool’s bench time, in the same spirit as HADR_WORK_QUEUE for Availability Groups.
Is It a Problem?
No; idle workers are the healthy state, and this wait is filtered as benign. Its totals reflect how many mirrored databases exist and how quiet they are, nothing about mirroring performance or safety.
If mirroring is actually struggling, the evidence is concrete elsewhere: send queue growth on the principal, redo queue on the mirror, DBMIRROR_SEND waits when the network chokes, and the mirroring state itself (SYNCHRONIZED vs SYNCHRONIZING) in sys.database_mirroring.
Common Causes
- Mirrored databases with little write activity, leaving workers idle.
- Multiple mirroring sessions each holding a mostly-idle worker crew.
What To Do
- Filter it out of wait analysis.
- Check
sys.database_mirroringstate and the mirroring counters when mirroring health is the actual question. - Keep the AG migration on the roadmap; the mirroring feature is deprecated.
How To See It
Rank waits with Get-WaitStatistics, and expect it wherever mirroring is configured, meaning nothing by its size.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply