PWAIT_DIRECTLOGCONSUMER_GETNEXT is recorded when a thread reading from the transaction log waits for a log block to be supplied to it. The direct log consumer interface serves the components that stream the log as it is produced, Availability Group capture being the flagship, and a consumer that has caught up to log generation waits here for the next block.
Caught-up log readers waiting for more log is the healthy resting state, the same story as HADR_LOGCAPTURE_WAIT one layer down.
Is It a Problem?
No; it has not been a contention point, and accumulation mostly measures how often log consumers are up to date. Filter it with the other log-reader idle waits.
Log consumers actually falling behind manifest in their features’ own metrics, AG send queues, CDC scan latency, not in this supply wait, which shrinks (not grows) when consumers are busy.
Common Causes
- Log-reading components caught up and waiting for new log blocks.
- Quiet write periods leaving consumers idle.
What To Do
- Filter it out of wait analysis.
- Judge log-consumer health through the owning features’ queues and latencies.
How To See It
Rank waits with Get-WaitStatistics; expect it as background noise wherever log-streaming features run.
Part of the SQL Server Wait Types Library.
Related deep dive: WRITELOG Wait Type.
Leave a Reply