Sintomas
Suponha que você tenha um AG (Grupo de Disponibilidade Always On) em SQL Server 2016 e 2017. Quando você processa uma consulta de leitura em um réplica secundário, o desempenho pode ser muito mais lento do que o réplica primário devido a esperas frequentes de DIRTY_PAGE_TABLE_LOCK.
Causa
Esse problema ocorre devido à contenção entre a consulta de leitura e o thread de refazer e porque a tabela está bloqueada.
Resolução
Essa correção está incluída nas seguintes atualizações para SQL Server:
Atualização cumulativa 8 para SQL Server 2017
Atualização cumulativa 1 para SQL Server Service Pack 2 de 2016
Atualização cumulativa 9 para SQL Server Service Pack 1 de 2016
Cerca de SQL Server builds
Cada novo build para SQL Server contém todos os hotfixes e correções de segurança que estavam no build anterior. Recomendamos instalar o build mais recente para sua versão do SQL Server:
Solução alternativa
Para contornar esse problema, você pode usar um único thread de refazer em vez de um thread de refazer paralelo, habilitando o Trace Flag 3459.
Informações adicionais
Quando as consultas somente leitura estão em execução em um réplica secundário legível, os threads de consulta tentam aplicar operações pendentes de refazer log e precisam colaborar com threads de trabalho refeitos com DIRTY_PAGE_TABLE_LOCK esperas, que podem ser geradas com frequência e reduzir o desempenho de refazer e consultar se houver cargas de trabalho de refazer simultaneamente. O problema de desempenho associado ao DIRTY_PAGE_TABLE_LOCK espera é resolvido na versão cumulativa de atualização para SQL Server 2016 SP e SQL Server 2017 mencionados neste artigo.
Para obter mais informações, você pode ver o blog a seguir no grupo de disponibilidade secundário réplica refazer o modelo e o desempenho.
Status
A Microsoft confirmou que este é um problema nos produtos Microsoft listados na seção "Aplicável a".
Referências
Saiba mais sobre a terminologia que a Microsoft usa para descrever atualizações de software.
