在活动异地复制中，异地辅助副本会持续接收并应用主副本的事务日志记录。 当次要副本无法像主副本生成日志时那样快地应用日志时，积压工作生成（重做队列）和时间差距增加（重做延迟）。 这种情况可能会影响辅助数据库上的只读新鲜度，并增加故障转移时间。
- 重做队列：异地复制传送到辅助数据库的事务日志量，但尚不适用。
- 重做延迟：在主要副本上提交事务与在辅助副本上完成重播之间的已用时间。
异地复制是异步的。 次要副本上的重做延迟不会导致主要副本上的等待，但重做延迟可能会导致次要副本上的数据落后。
症状
- 辅助服务器上的陈旧数据用于只读工作负载（报告、分析或转移读取）。
- 更长的故障转移时间，这会增加恢复时间目标（RTO）。
- 辅助系统承受持续的资源压力，降低了其跟上进度的能力。
- 确认 DMV sys.dm_database_replica_states中的重做滞后时间，如果
redo_queue_size > 0正在增加并且secondary_lag_seconds也在增加。
为什么重做积压任务会增长
尽管辅助数据库是只读的，但它仍会维护用于内部作的事务日志，包括从主数据库重播日志记录。 重做队列增长时，辅助数据库必须保留更多事务日志数据。
这种情况可能导致：
- 辅助数据库上的事务日志增长。
- 更高的存储消耗量，这可能会影响成本和性能。
- 超出阈值时的潜在限制情景。
副本大小不匹配的影响
应使用相同的服务级别目标（SLO）、备份存储冗余、 计算层 （预配或无服务器）和计算大小（DTU 或 vCore）配置主副本和异地辅助副本。
如果配置计算大小低于主数据库的辅助数据库，则可能会遇到以下情况：
- 辅助（CPU、I/O）上的资源争用会降低重做操作的速度。
- 无法跟上主数据库的事务日志生成速率。
- 增加重做队列大小，这会使延迟恶化并降低复制有效性。
建议
为了减少重做延迟，维护次要副本上的复制运行状况和日志的高效使用，请按照以下步骤操作：
对齐 SLO 和计算尺寸。 确保辅助数据库的性能层与主数据库相同。
- 配置地理次级数据库： 活动异地复制
- 缩放单一数据库：
在 Azure SQL Database - 缩放弹性池：缩放 Azure SQL Database 中的弹性池资源
定期监视。 使用动态管理视图（例如 sys.dm_database_replica_states ）跟踪重做延迟和队列大小。 当
redo_queue_size > 0得到确认，并且secondary_lag_seconds正在增加时，表明恢复滞后的出现。优化工作负荷：
- 减少辅助数据库上长时间运行的事务，并降低主数据库上的高日志生成峰值。
- 避免在高峰期重新生成大型索引。 重新生成可以获取架构修改（SCH-M）锁，这些锁可能会阻止辅助服务器上的重做线程，并导致重做队列的生成。
- 减少辅助数据库上长时间运行的事务，并降低主数据库上的高日志生成峰值。