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.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply