我们有一个大型物理服务器,上面有 50 多个 dbs;有些人很忙,有些人很安静。
当 AG 中有多个 DB 时,只有其中一些 DB 具有多个重做线程。我们希望具有这些线程的数据库成为繁忙的数据库。在最近的一次迁移中,我们决定注意恢复数据库的顺序,因为我们理解这是根据数据库创建日期决定的。但是,检查迁移后,这是不正确的。
SELECT databases.database_id,
databases.create_date,
dm_hadr_db_threads.name,
dm_hadr_db_threads.num_redo_threads,
dm_hadr_db_threads.num_parallel_redo_threads
FROM sys.dm_hadr_db_threads
INNER JOIN sys.databases ON dm_hadr_db_threads.name = databases.name
ORDER BY
dm_hadr_db_threads.num_redo_threads DESC
OPTION (RECOMPILE)
它不是创建日期或数据库 ID。它不是按字母顺序排列的。它不是添加到 ag 的顺序。有谁知道这是什么决定的?
这是 SQL Server 2019;查询来自二级。
这是我们发现它基于 database_id 的地方:https ://www.brentozar.com/archive/2018/06/first-responder-kit-release-just-when-you-think-theres-nothing-new-left -去做/
并行重做线程按数据库恢复顺序分配,该顺序确实遵循
sys.databases
创建日期。也就是说,单独的并行数据库恢复 功能意味着可以将每个数据库恢复任务分配给不同的 SOS 调度程序(当有足够多的调度程序可用时)。
假设您有 8 个数据库和 32 个处理器。8 个单独的恢复任务可能会分配给 8 个不同的调度程序(CPU 的 SOS抽象)。8 个任务的创建(按创建日期顺序)和调度程序分配可以很快发生。
每个调度程序多快(以及以何种顺序)开始执行其分配的恢复任务取决于每个调度程序当时还有哪些其他工作(其可运行队列),以及任何其他当前活动任务通过当前时间片的距离。
在每个独立的恢复任务开始在其分配的调度程序上执行后不久,就会分配并行重做线程(直至全局限制)。由于上述问题,这是不确定的。
Microsoft 支持有一些未记录的跟踪标志,可以帮助促进在复杂场景中并行重做线程的良好分布。您应该就您的情况与他们联系。