PARALLEL_REDO_WORKER_WAIT_WORK Wait Type in SQL Server

PARALLEL_REDO_WORKER_WAIT_WORK is recorded on an Availability Group secondary when one of the parallel redo worker threads is waiting to be given log records to replay. Most of the time that is because the primary simply is not generating log right now, so the workers idle.

It is the opposite condition to PARALLEL_REDO_FLOW_CONTROL: there, workers are too busy; here, they have nothing to do.

Is It a Problem?

No. This wait accumulating, even in large amounts, mostly measures quiet time on the primary. Every AG database gets a set of parallel redo workers, and each idle worker clocks up this wait continuously, so on secondaries hosting many databases it can be enormous in a raw wait ranking while meaning nothing at all.

The rare edge case, the main redo thread failing to dispatch as fast as workers can apply, still is not something you act on through this wait; you would see it as redo lag in the DMVs.

Common Causes

• Low or bursty log generation on the primary, leaving redo workers idle between bursts.
• Many AG databases each holding a pool of mostly-idle redo workers.
• Overnight and weekend quiet periods.

What To Do

1. Filter it out of wait analysis alongside the other benign background waits.
2. Judge redo health by redo_queue_size and redo_rate in sys.dm_hadr_database_replica_states, never by this wait.
3. If you genuinely suspect redo dispatch is the bottleneck (rare), look for high PARALLEL_REDO_FLOW_CONTROL and a growing redo queue on the same database; idle-worker time is not evidence either way.

How To See It

Rank waits with Get-WaitStatistics and expect this one to be filtered or ignored on AG secondaries. Its size tracks idle capacity, not workload health.

---

Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.