Sintomas
Suponha que tem um Grupo de Disponibilidade AlwaysOn (AG) no SQL Server 2016 e 2017. Quando processa uma consulta de leitura numa réplica secundária, o desempenho pode ser muito mais lento do que a réplica primária devido a esperas frequentes de DIRTY_PAGE_TABLE_LOCK.
Causa
Este problema ocorre devido à contenção entre a consulta de leitura e o thread de refazer e porque a tabela está bloqueada.
Resolução
Esta 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
Acerca das SQL Server builds
Cada nova compilação para SQL Server contém todas as correções e correções de segurança que estavam na compilação anterior. Recomendamos que instale a compilação mais recente para a sua versão do SQL Server:
Solução
Para contornar este problema, pode utilizar um único thread de refazer em vez de um thread de refazer paralelo ao ativar o Sinalizador de Rastreio 3459.
Mais Informações
Quando as consultas só de leitura estão em execução numa réplica secundária legível, os threads de consulta tentam aplicar operações de fase de rollforre de registo pendentes e precisam de colaborar com threads de trabalho de fase de DIRTY_PAGE_TABLE_LOCK esperas , que podem ser geradas frequentemente e abrandar o desempenho de repetição e consulta se existirem cargas de trabalho de repetição simultâneas. O problema de desempenho associado à espera de DIRTY_PAGE_TABLE_LOCK é resolvido na versão de atualização cumulativa do SP SQL Server 2016 e SQL Server 2017 mencionados neste artigo.
Para obter mais informações, pode ver o seguinte blogue sobre o desempenho e o modelo de redo da réplica secundária do Grupo de disponibilidade.
Estado
A Microsoft confirmou que este problema ocorre nos produtos da Microsoft listados na secção "Aplica-se a".
Referências
Saiba mais sobre a terminologia que a Microsoft utiliza para descrever as atualizações de software.
