No artigo anterior, comentei sobre a vantagem de usar o SET STATISTICS IO como ferramenta de análise de performance.
Terminei o artigo o mistério: por que o número de read-ahead e logical reads não bate?
O resultado esperado deveria ser:
Limpando o Buffer Bool
O comando DBCC DROPCLEANBUFFERS remove as páginas do banco de dados do cache. Entretanto, o próprio nome já diz: ele remove somente as páginas limpas e que são seguras para serem descartadas. As páginas que possuem modificação são chamadas de suja e não podem ser descartadas enquanto não forem gravadas em disco. Essa explicação está na referência do comando.
DBCC DROPCLEANBUFFERS
https://msdn.microsoft.com/en-us/library/ms187762.aspx
Podemos confirmar esse comportamento através das DMV sys.dm_os_buffer_descriptors:
Esse comportamento muda após rodar o CHECKPOINT manualmente:
Depois rodar novamente o DBCC DROPCLEANBUFFERS.
Resultado
O resultdo final foi que o número de logical reads (1257) é igual a read-ahead pages (1257).
Um fato interessante é que o tempo aumentou de 369ms para 852ms.
Parece que o banco de dados está ficando mais lento.
Sempre é possível piorar!
Vamos desligar as operações de Read-Ahead no servidor inteiro usando o Trace Flag Global 652.
Em seguida, limpamos o cache de dados e rodamos novamente a query.
Enquanto no artigo anterior a query rodava em 1ms, parece que batemos nosso recorde e chegamos a 1485ms.
Conclusão
Limpando o cache e desligando o comportamento de read-ahead afetou o desempenho da query sem mudar nenhum código. Aproveito para avisar de alguns cuidados:
- Não use DBCC DROPCLEANBUFFERS em produção.
- Evite consultar a view sys.dm_os_buffer_descriptors
- Jamais ligue o Trace Flag 652 em produção
No próximo artigo, vamos explorar melhor o mecanismo de read-ahead e tentar uma forma de piorar (?) o desempenho de forma mais acentuada.