DBCC DROPCLEANBUFFERS

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.