DUMP_LOG_COORDINATOR is recorded when the coordinator thread of an fn_dump_dblog operation waits for its sub-threads to complete work. fn_dump_dblog is the undocumented function for reading log records directly out of a backup (its sibling fn_dblog reads the live log), a forensics tool for questions like “who deleted those rows and when”. Its companion DUMP_LOG_COORDINATOR_QUEUE covers the same machinery’s work queue, and this page covers both.
Books Online’s description (“a long wait indicates an unexpected blockage”) predates the repurposing; seeing these waits during fn_dump_dblog runs is simply normal.
Is It a Problem?
No; the waits track your own log-dumping activity and nothing else. Long accumulations mean long forensic reads, which big backups produce naturally.
One operational caution belongs with the function rather than the wait: fn_dump_dblog historically created hidden threads that were not cleaned up until restart on older versions, so casual production use of the function deserves restraint. Doing log forensics against a restored copy elsewhere is the tidier pattern anyway.
Common Causes
fn_dump_dblogreading log records from backup files during investigations.
What To Do
- Filter the waits; they meter your own forensics.
- Prefer running log archaeology on a restored copy off the production instance.
- For live-log questions,
fn_dblog(also undocumented) reads the active log with lighter machinery.
How To See It
Rank waits with Get-WaitStatistics; occurrences match your own investigative sessions exactly.
Part of the SQL Server Wait Types Library.
Related deep dive: WRITELOG Wait Type.
Leave a Reply