This wait type is usually when the main redo thread in an Availability Group replica has dispatched as much as log as it can to the parallel redo threads and is waiting for one of them to complete its redo work so that more log can be dispatched for redoing. It can also occur during crash recovery of a database that is not part of an Availability Group.
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:2016Removed in SQL Server version:N/AExtended Events wait_type value:The map_key value in sys.dm_xe_map_values is 1130 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:In an AG, this wait occurs because the parallel redo threads either cannot keep up with the volume of log being sent for redo by the main redo thread for some reason. On some servers running builds before SQL Server 2016 SP1 CU2, this wait type is the symptom of a crippling bottleneck during redo of transaction log records on an AG replica. If you are experiencing this wait type as one of the highest waits on your AG secondaries, you can disable 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.
On a non-AG database, this wait type can occur if the number of VLFs in the transaction log is very high and there is a large amount of UNDO recovery to perform. In that case, reduce the number of VLFs to prevent the issue from happening again in future.
You can read more about parallel redo in this blog post.
Known occurrences in SQL Server (list number matches call stack list):- TBD
- TBD