Estou vendo um aumento no PAGELATCH
, PAGEIOLATCH
e WRITELOG
aguarda após a migração para o SQL Server 2017 (do SQL Server 2008). Enquanto eu posso explicar o aumento PAGEIOLATCH
e WRITELOG
(temos outros discos - HDD em vez de SSD), mas não sei porque PAGELATCH
sobe também.
Eles estão de alguma forma relacionados?
O que eu vejo ao redor eles não são, porque PAGELATCH
pertence à memória, enquanto os outros ao IO.
Eu não chegaria a essa conclusão sem fazer mais análises. Algumas das possíveis causas que Paul Randal mencionou neste artigo.
Aqui estão algumas possíveis causas raiz (não uma lista exaustiva):
Um plano de consulta fazendo uma verificação de tabela/índice clusterizado (em vez de uma busca de índice) devido a:
Eles estão de alguma forma relacionados?
Não. Leia este artigo para possíveis causas e soluções.
Knee-Jerk Wait Statistics: PAGELATCH por Paul Randal.
Leia também a resposta desta pergunta.
Alta espera de PAGELATCH_* e WRITELOG. Eles estão relacionados?
Sugiro que você analise sua carga de trabalho e identifique o que mudou entre 2008 e 2017. Tente correlacionar essas mudanças com a mudança em seu tipo de espera. O estimador de cardinalidade novo e aprimorado foi lançado no SQL Server 2014, o que pode não produzir um plano ideal para todo o seu código escrito para 2008. Lembre-se de que a mudança de hardware também pode desempenhar um papel. Depois de ter todas as informações, você poderá identificar a causa raiz das alterações no tipo de espera.
O estimador de cardinalidade novo e aprimorado no SQL Server 2014