DBMIRRORING_CMD is recorded when a thread waits for various database mirroring configuration and state change operations to complete, a bucket that includes waiting on log flushes within the mirroring machinery. Books Online notes this wait is expected to be held for long periods, and mirrored instances routinely show many of them.
It is broad mirroring plumbing rather than one specific operation.
Is It a Problem?
Usually not; it is typical background residue on any mirrored instance and normally filtered out. The one situation where it earns a look: if it ranks among your most prevalent waits and you have mirroring performance complaints, anecdotal evidence points at the log flush component, specifically the I/O performance of the mirror database’s log file. Faster log storage on the mirror side has resolved cases matching that picture.
Otherwise, filter and move on.
Common Causes
- Normal mirroring configuration and state machinery across mirrored databases.
- Log flush waits inside the mirroring path, stretched by slow mirror-side log storage.
What To Do
- Filter it in routine analysis.
- If mirroring is slow and this wait is prominent, measure log write latency on the mirror server (
sys.dm_io_virtual_file_statsthere); upgrade that path if it is the laggard. - As with the whole mirroring family: the durable fix for mirroring pain is the migration to Availability Groups.
How To See It
Rank waits with Get-WaitStatistics, treating it as noise unless mirroring performance is the open question.
DBMIRRORING_CMD 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