PARALLEL_REDO_TRAN_TURN

(Republishing, or using this info in a commercial product/website, is prohibited without permission. All other uses are permitted. If in doubt, please ask.)

(Back to main page…)

Description:

This wait type is when a parallel redo thread on an Availability Group readable secondary replica needs to redo a log record, but there is another log record that must be redone first, and another parallel redo thread has not yet redone it. In other words, an operation occurred on the primary replica for which the log records must be redone in the correct order (either a page split or the generation of a forwarded record in a heap) and the log records for the operation were given to two or more parallel redo threads to redo, causing one of them to be delayed.

Questions/comments on this wait type? Click here to send Paul an email, especially if you have any information to add to this topic.

Added in SQL Server version:

2016

Removed in SQL Server version:

N/A

Extended Events wait_type value:

The map_key value in sys.dm_xe_map_values is 1136 in 2016 RTM. After 2016 RTM, you must check the DMV to get the latest value as some map_key values have changed in later builds.

Other information:

This wait type can be a bottleneck for parallel redo performance for a readable secondary replica if there are significant amounts of page split activity or heap forwarded record generation on the primary replica. Solutions to this include:

• Reducing the number of page splits in the primary replica. You can do this by figuring which indexes are having page splits (which will likely result in PAGELATCH_EX waits) and then usually implementing fill factors and regular index maintenance.
• Reducing the number of heap forwarded records that are created. You can do this by creating clustered indexes on those tables that are heaps with many forwarded records. You can identify these tables by monitoring the forwarded_record_countsys.dm_db_index_physical_stats values in the output of the DMV .
• Disabling parallel redo by turning on trace flag 3459 using DBCC TRACEON (3459, -1), or adding it as a startup trace flag using the Configuration Manager. The trace flag does not come into effect until the instance is restarted.

You can read more about parallel redo in this blog post.

Known occurrences in SQL Server (list number matches call stack list):

1. TBD

Abbreviated call stacks (list number matches known occurrences list):

1. TBD