Sintomas
Suponha que você tenha um grupo de disponibilidade contínua (AG) do SQL Server 2016 e do 2017. Ao processar uma consulta de leitura em uma réplica secundária, o desempenho pode ser muito menor do que a réplica primária devido a esperas DIRTY_PAGE_TABLE_LOCK frequentes.
Causa
Esse problema ocorre devido à disputa entre a consulta leitura e o thread de refazer, e como a tabela está bloqueada.
Resolução
Esta correção está incluída nas seguintes atualizações do SQL Server:
Atualização cumulativa 8 para SQL Server 2017
Atualização cumulativa 1 para SQL Server 2016 Service Pack 2
Atualização cumulativa 9 para SQL Server 2016 Service Pack 1
Sobre as compilações do SQL Server
Cada novo Build do SQL Server contém todos os hotfixes e correções de segurança que estavam na compilação anterior. Recomendamos instalar o Build mais recente para a sua versão do SQL Server:
Solução alternativa
Para contornar esse problema, a ou ypode usar um único thread de refazer, em vez de um thread de restauração paralela, habilitando o sinalizador de rastreamento 3459.
Informações adicionais
Quando as consultas somente leitura estiverem em execução em uma réplica secundária legível, os threads de consulta tentam aplicar operações de reoperação de logs pendentes e precisam colaborar com os threads de trabalho redo com DIRTY_PAGE_TABLE_LOCK esperas, o que pode ser gerado com frequência e retardar o desempenho de refazer e de consulta se houver cargas de trabalho redo simultâneas. O problema de desempenho associado à espera de DIRTY_PAGE_TABLE_LOCK é abordado na versão de atualização cumulativa do SQL Server 2016 SP e SQL Server 2017 mencionada neste artigo.
Para saber mais, você pode ver o seguinte blog sobre o grupo de disponibilidade refazer o modelo e o desempenho da réplica secundária.
Status
A Microsoft confirmou que este é um problema nos produtos Microsoft que estão listados na seção "Aplicável a".
Referências
Saiba mais sobre a terminologia usada pela Microsoft para descrever atualizações de software.
