PARALLEL_REDO_TRAN_LIST is recorded when the main parallel redo thread on an Availability Group replica needs access to the shared list of transactions currently being redone. That list is mostly the working territory of the parallel redo worker threads, so the main thread’s occasional visits usually get straight in, and this wait stays rare.
Another of the redo family’s internal coordination waits.
Is It a Problem?
No; it is part of normal parallel redo operations and documented as not indicating a performance issue. Expect it at or near zero even on busy secondaries, with occasional small values during heavy redo periods.
As with all the redo bookkeeping waits, real redo health is measured by the queue and rate DMV columns and by PARALLEL_REDO_FLOW_CONTROL, not by the coordination residue.
Common Causes
- Normal main-thread access to the shared transaction list during parallel redo.
- Busy redo periods slightly raising the collision odds.
What To Do
- Filter it out of wait analysis.
- Track redo health through
sys.dm_hadr_database_replica_stateswhen it matters. - No direct action exists for this wait.
How To See It
Rank waits with Get-WaitStatistics; it should barely register, and means nothing when it does.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply