可用性组复制延迟

Question

为诊断以下问题的根本原因寻找思路。我们有三个可用节点--初级、同步副本、异步副本。同步副本上不存在T-日志备份以外的负载.在某个时候，所有的复制品都开始落后。滞后时间在6小时内增加。数据仍在编写中，但速度非常慢。突然，复制品开始迎头赶上，并在30分钟左右的时间内恢复到最新的水平。任何Server错误日志中都没有错误。没有阻塞DB启动进程或副本上的任何重做进程(其中一个副本上没有用户)，HADR_DATABASE_FLOW_CONTROL已移动到顶部等待次要顶部等待的主进程通常是PARALLEL_REDO_WORKER_WAIT REDO_THREAD_PENDING_WORK PARALLEL_REDO_TRAN_TURN

在这个问题上，除了PARALLEL_REDO_FLOW_CONTROL之外，这个问题几乎没有改变。

没有证据显示主服务器上存在长时间运行的大型事务。考虑到所有副本都受到影响，它指出了主副本的一个问题。没有索引维护类型作业正在运行。有人能想到任何ddl、dml操作或其他可能导致这种行为的任务吗？谢谢

环境都是SQL2016 CU9，磁盘在所有机器上都是本地的。

Answer 1

考虑到主服务器上存在高HADR_DATABASE_FLOW_CONTROL等待，而PARALLEL_REDO_FLOW_CONTROL和PARALLEL_REDO_TRAN_TURN的组合则在次要位置上等待，看起来并行重做可能并不适合您的工作负载。

有人能想到任何ddl、dml操作或其他可能导致这种行为的任务吗？

微软在他们的关于并行重做的博客文章中举了一个例子：

只有在新插入触发器分页系统事务或堆表中的记录更新生成转发记录时，PARALLEL_REDO_TRAN_TURN才会发生在可读的辅助副本中。

如果工作负载导致大量分页或转发记录，则应考虑通过打开记录在案的跟踪标志3459 (注意:作为永久解决方案，希望将其设置为Server配置管理器中的启动跟踪标志)，从而禁用辅助设备上的并行重做：

DBCC TRACEON (3459,-1);

如果需要恢复到在构建中使用并行重做，则需要在禁用跟踪标志后重新启动Server服务。在SP1 CU10和SP2 CU2中，这是固定的(不需要重新启动)。它看起来不像是在RTM分支中固定的。有关详细信息，请参阅此KB：https://support.microsoft.com/en-us/help/4339858/fix-parallel-redo-does-not-work-after-you-disable-trace-flag-3459-in-a

更广泛地说，对于SP1和SP2中的并行重做问题，有几个解决方法。您应该考虑修补Server，以查看这是否也解决了您的问题。

如果您想确认正在活跃地发生分页或转发抓取，请尝试运行服务提供商_BlitzFirst：

EXEC dbo.sp_BlitzFirst;

如果要确认堆中有大量转发记录，可以使用类似于此的DMV查询(注意:用数据库中堆的名称替换Your_Table_Name )：

SELECT 
    OBJECT_NAME(object_id) AS table_name, 
    forwarded_record_count,
    page_count
FROM sys.dm_db_index_physical_stats 
(
    DB_ID(), 
    OBJECT_ID(N'Your_Table_Name'), 
    DEFAULT, 
    DEFAULT, 
    'DETAILED'
);