Sintomas
Assuma que tem um Grupo De Disponibilidade Sempre (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 frequentes DIRTY_PAGE_TABLE_LOCK esperas.
Causa
Esta questão ocorre devido à discórdia entre a consulta de leitura e o fio de redo, e porque a tabela está bloqueada.
Resolução
Esta correção está incluída nas seguintes atualizações para o 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 construções do SQL Server
Cada nova construção para SQL Server contém todos os hotfixes e correções de segurança que estavam na construção anterior. Recomendamos que instale a mais recente construção para a sua versão do SQL Server:
Solução
Para contornar esta questão, podeutilizar um único fio de redo em vez de um fio de redo paralelo, permitindo o Trace Flag 3459.
Mais Informações
Quando as consultas apenas de leitura estão a decorrer numa réplica secundária legível, os fios de consulta tentam aplicar operações de repetição de registos pendentes e precisam de colaborar com fios de trabalhador redo com DIRTY_PAGE_TABLE_LOCK esperas, que podem ser frequentemente geradas e retardadas tanto o desempenho de repetição como o desempenho de consulta se houver cargas de trabalho recorrentes. O problema de desempenho associado à espera de DIRTY_PAGE_TABLE_LOCK é abordado no lançamento acumulado da atualização para o SQL Server 2016 SP e SQL Server 2017 mencionado neste artigo.
Para mais informações, pode ver o seguinte blog sobre o modelo e desempenho de réplica secundária do grupo Availability.
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 atualizações de software.
