CORREÇÃO: Desempenho é lento para um sempre em AG ao processar uma consulta no SQL Server de leitura

Aplica-se a: SQL Server 2016 DeveloperSQL Server 2016 EnterpriseSQL Server 2016 Enterprise Core

Sintomas


Suponha que você tenha um sempre em disponibilidade grupo (AG) no SQL Server 2016 e 2017. Ao processar uma consulta de leitura em uma cópia secundária, o desempenho pode ser muito mais lento do que a réplica principal devido a espera frequente de DIRTY_PAGE_TABLE_LOCK.

Causa


Esse problema ocorre devido à contenção entre a leitura de consulta e thread refazer, e porque a tabela está bloqueada.

Resolução


Essa correção está incluída na seguintes atualizações para SQL Server:

Atualização cumulativa 8 para SQL Server 2017 

Atualização cumulativa 1para o SQL Server 2016 Service Pack 2

Atualização cumulativa 9 para o SQL Server 2016 Service Pack 1

Solução alternativa


Como solução alternativa para esse problema you usar uma thread redo único em vez de um segmento de redo paralelo, permitindo o rastreamento sinalizador 3459.

Informações adicionais


Quando estiver executando consultas somente leitura em uma réplica secundária legível, segmentos de consulta tentar aplicar pendentes log refazer operações e precisam colaborar com segmentos de trabalho Refazer com espera DIRTY_PAGE_TABLE_LOCK , que pode ser gerado com frequência e diminuir Refazer e o desempenho da consulta se houver simultâneas Refa as cargas de trabalho. O problema de desempenho associado a espera DIRTY_PAGE_TABLE_LOCK é abordado na edição de atualização cumulativa para SQL Server 2016 SP e SQL Server 2017 mencionadas neste artigo.

Para obter mais informações, você pode ver o seguinte blog na réplica secundária do grupo de disponibilidade refazer o modelo e o desempenho.

Status


A Microsoft confirmou que este é um problema nos produtos Microsoft que estão listados na seção "Aplicável a".

Referências


Conheça a terminologia que a Microsoft usa para descrever as atualizações de software.