Sqlserver2016启用了日志并行，但是实际上某些数据库日志并行并没有生效的问题

https://docs.microsoft.com/en-us/archive/blogs/sql_server_team/sql-server-20162017-availability-group-secondary-replica-redo-model-and-performance

sqlserver2016默认启动并行

禁用并行2种方法
1、DBCC TRACEON (3459, -1)，不用重启sqlserver服务
2、-T 3459参数加入sqlserver启动参数

禁用串行再启用并行，必须重启sqlserver
如果有-T 3459参数，则移除该参数，再重启sqlserver
如果是DBCC TRACEON (3459, -1)， 则直接重启sqlserver

现象：wondadb3上有20来个数据库做了AG到dbprod126，dbprod126只有24个CPU，发现wondadb3.wondb到dbprod126.wondb的AG传输很慢，把所有数据库移出AG，再重新加入，加入的过程中第一个先加入wondb，在加入其它所有数据库，发现wondadb3.wondb到dbprod126.wondb的AG传输快了很多，发现sqlserver2016的并行设计上有缺陷，数据库数量一多，排后面的几个数据库就只能默认使用串行

官方文档的解释：
Parallel redo thread usage is well covered in “Thread usage by Availability Groups” here.

A SQL Server instance uses up to 100 threads for parallel redo for secondary replicas. Each database uses up to one-half of the total number of CPU cores, but not more than 16 threads per database. If the total number of required threads for a single instance exceeds 100, SQL Server uses a single redo thread for every remaining database.

When the host server has 32 or more CPU cores, each database will occupy 16 parallel redo worker threads and one helper worker thread. It means that all databases starting with the 7th database (ordered by database id ascending) that has joined availability group it will be in single thread redo or serial redo irrespective which database has actual redo workload. If a SQL Server Instance has a number of databases, and it is desired for a particular database to run under parallel redo model, the database creation order needs to be considered. Same idea can be
applied to force a database always runs in serial redo model as well. Again, in SQL Server instance level, the way to switch between parallel redo and serial redo is the TF 3459. All databases in the same SQL Server instance will be switched together. Also, to switch from serial redo to parallel redo by disable TF 3459, a SQL Server service restart is required

一个数据库最高并发线程数量的计算
一个AG从节点实例最多有100个并行的redo重做线程，但是每个数据库最多只有一半的cpu数据的线程，但是最多又不能超过16个，假如一台服务器24个cpu，20个数据库加入了AG，则使用每个数据库的最多不能超过8(100/12=8)

实践得出结论
1、此处的加入AG的顺序，不是代表数据第一次加进AG的顺序，而是数据库启动后数据库加进AG的顺序。
假如10个库，名称分别是1-10，1开始1号库是用上了并行，但是1号库产生的日志特别大，某天突然从库重启后，从库上的1号库要花很长时间来恢复无法及时进入Synchronizing状态，这个时候其他数据库正常恢复完了马上进入了Synchronizing，1号库又排在后面用不上并行
2、一个库同步很慢，没有用上并行，而且同步队列还有100GB待同步，同步速度只有50M每秒，还需要1小时才能同步完，这个时候可以在主节点把其他库包括它自己都移出AG，移除后，从节点看到已经同步完的数据库的的状态是restoring，没有同步完的数据库的状态会是not Synchronizing，等1小时候not Synchronizing变成restoring后，再添加进AG，添加的过程会很快，且这个库的状态会是(Initializing/In recovery)，但是在not Synchronizing到restoring这1小时期间主节点生成的日志需要同步到从节点，这1小时期间生成的日志需要30分钟才能同步到从节点，但是此时因为这个库以第一的顺序加入了AG，使用了并行，比如并行度为8，这个(Initializing/In recovery)也会很快完成，只需要4分钟(30分钟/8)左右就能完成
3、查看一个AG库有没有用上并行，查询sys.sysprocesses该库对应的cmd自动是否为"PARALLEL REDO TA"即可,为"PARALLEL REDO TA"，说明用上了并行