Temos um grande servidor físico com mais de 50 dbs; alguns são bastante ocupados, outros muito tranquilos.
Ao ter vários bancos de dados em um AG, apenas alguns deles vários threads de redo. Queríamos que os bancos de dados com esses encadeamentos fossem os ocupados. Durante uma migração recente, decidimos ter cuidado com a ordem em que restauramos os dbs, pois entendemos que isso foi decidido com base na data de criação dos bancos de dados. No entanto, verificando a pós-migração, isso não é verdade.
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)
Não é a data de criação ou o ID do banco de dados. Não é alfabético. Não é pedido adicionado ao ag. Alguém sabe o que decide isso?
Este é o SQL Server 2019; a consulta é do secundário.
Aqui é onde descobrimos que era baseado em database_id: https://www.brentozar.com/archive/2018/06/first-responder-kit-release-just-when-you-think-theres-nothing-new-left -façam/
Os threads de redo paralelos são atribuídos na ordem de recuperação do banco de dados , que segue a
sys.databases
data de criação.Dito isso, o recurso de recuperação de banco de dados paralelo separado significa que cada tarefa de recuperação de banco de dados pode ser atribuída a um agendador SOS diferente (quando houver um número grande o suficiente de agendadores disponíveis).
Digamos que você tenha 8 bancos de dados e 32 processadores. As 8 tarefas de recuperação separadas provavelmente seriam atribuídas a 8 agendadores diferentes (a abstração SOS de uma CPU). A criação das 8 tarefas (em ordem de data de criação) e as atribuições do agendador podem acontecer muito rapidamente.
A rapidez (e em que ordem) cada agendador começa a executar sua tarefa de recuperação atribuída depende de qual outro trabalho cada agendador tem no momento (sua fila executável) e a que distância do quantum atual está qualquer outra tarefa atualmente ativa.
Os threads de redo paralelos são atribuídos (até o limite global) logo após cada tarefa de recuperação independente começar a ser executada em seu agendador atribuído. Isso não é determinístico devido ao problema descrito acima.
O suporte da Microsoft tem alguns sinalizadores de rastreamento não documentados que podem ajudar a promover uma boa distribuição de threads de redo paralelos em cenários complexos. Você deve contatá-los sobre sua situação.