PARALLEL_REDO_TRAN_TURN is recorded on an Availability Group readable secondary when a parallel redo thread must redo a log record, but a prerequisite log record has not yet been redone by another thread. Some operations demand strict ordering, page splits and the creation of forwarded records in heaps are the documented ones, and when their log records land on different redo threads, one thread waits its turn.
It is the price of parallel redo meeting order-sensitive log records.
Is It a Problem?
This one, unlike most of its family, can genuinely bottleneck redo on a readable secondary. The driving condition lives on the primary: significant page split activity or heap forwarded-record generation produces streams of order-dependent log records, and the secondary’s redo parallelism degrades toward serial behaviour applying them.
If your readable secondary lags and this wait features, the fix is index and table hygiene on the primary, which is a satisfying diagnosis: better fill factors over there speed up redo over here.
Common Causes
- Page splits on the primary (also visible there as
PAGELATCH_EXand fragmentation churn). - Heaps taking updates that generate forwarded records.
- Bursts of order-sensitive DML during load windows.
What To Do
- Confirm the pairing: redo lag on the secondary plus this wait, and page split indicators on the primary (fragmentation growth,
Page Splits/sec). - Reduce splits at the source: appropriate fill factors on hot indexes, and fix ever-ascending-key hotspots where relevant.
- Deal with heaps: forwarded records mean a heap taking updates, which usually deserves a clustered index anyway (our index design checks flag these).
- Re-measure redo rate after the primary-side hygiene; the improvement shows up in the DMVs.
How To See It
Rank it against everything else with Get-WaitStatistics on the secondary, paired with split and heap metrics from the primary.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply