Ao comparar o tempo de execução de duas consultas diferentes, é importante limpar o cache para garantir que a execução da primeira consulta não altere o desempenho da segunda.
Em uma Pesquisa do Google, eu pude encontrar estes comandos:
DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE
De fato, minhas consultas estão demorando mais para serem concluídas após várias execuções do que antes. No entanto, não tenho certeza se essa é a técnica recomendada.
Qual é a melhor prática?
Respostas:
Pessoalmente, para uma consulta comum, a segunda e as execuções subseqüentes são mais importantes.
Você está testando E / S de disco ou desempenho de consulta?
Supondo que sua consulta seja executada com frequência e seja crítica, você deseja medir isso em condições da vida real. E você não deseja limpar os caches do servidor prod toda vez ...
Se você quiser você pode:
DBCC DROPCLEANBUFFERSlimpa páginas limpas (não modificadas) do pool de buffers CHECKPOINTpara limpar primeiro as páginas sujas no discoDBCC FLUSHPROCINDB limpa os planos de execução para esse banco de dadosVeja também (no DBA.SE)
DECLARE @myDb AS INT = DB_ID(); DBCC FLUSHPROCINDB(@myDb); GOdaqui: stackoverflow.com/questions/7962789/…
Resposta tardia, mas pode ser útil para outros leitores
DBCC DROPCLEANBUFFERS é um comando frequentemente usado para testar e medir a velocidade de execução de consultas. Este comando (quando executado) deixa para trás apenas as páginas sujas, que na verdade são uma pequena parte dos dados. Remove todas as páginas limpas de um servidor inteiro.
Esteja ciente de que este comando não deve ser executado no ambiente de produção. A execução desse comando resultará em um cache de buffer quase vazio. A execução de qualquer consulta após a execução do comando DBCC DROPCLEANBUFFERS, utilizará leituras físicas para trazer de volta os dados para o cache, o que provavelmente será muito mais lento que a memória.
Mais uma vez, trate esse comando da mesma forma que o DBCC FREEPROCCACHE - ele não deve ser executado em nenhum servidor de produção, a menos que você saiba absolutamente o que está fazendo.
Essa pode ser uma ferramenta de desenvolvimento útil, pois você pode executar uma consulta em um ambiente de teste de desempenho repetidamente, sem alterações na velocidade / eficiência devido ao armazenamento em cache de dados na memória.
Saiba mais em: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/
Sempre me disseram para usar:
dbcc dropcleanbuffers;Do MSDN :
Use DBCC DROPCLEANBUFFERS para testar consultas com um cache de buffer frio sem desligar e reiniciar o servidor.
Para descartar buffers limpos do buffer pool, primeiro use CHECKPOINT para produzir um cache de buffer frio. Isso força todas as páginas sujas do banco de dados atual a serem gravadas no disco e limpa os buffers. Depois de fazer isso, você poderá emitir o comando DBCC DROPCLEANBUFFERS para remover todos os buffers do buffer pool.
DBCC FREEPROCCACHEpara limpar os planos de execução em cache ...
As outras respostas estão corretas sobre os motivos para não executar DBCC FREEPROCCACHE. No entanto, também existem alguns motivos para fazê-lo:
Se você deseja comparar duas consultas ou procedimentos diferentes que estão tentando fazer a mesma coisa de maneiras diferentes, é provável que cheguem às mesmas páginas. Se você executar ingenuamente a consulta nº 1 e a consulta nº 2, a segunda poderá ser muito mais rápida, simplesmente porque essas páginas foram armazenadas em cache pela primeira consulta. Se você limpar o cache antes de cada execução, eles começarão em pé de igualdade.
Se você quiser testar o desempenho do cache quente, execute as consultas várias vezes, alternando e descartando as primeiras execuções. Média dos resultados.
Digamos que você tenha uma consulta que leva um segundo em um cache quente, mas um minuto em um cache frio. Uma otimização que torna a consulta na memória 20% mais lenta, mas a consulta vinculada à IO 20% mais rápida pode ser uma grande vitória: durante operações normais, ninguém notará os 200 ms extras em circunstâncias normais, mas se algo forçar uma consulta a executar no disco, levar 48 segundos em vez de 60 pode salvar uma venda.
Isso é menos preocupante em sistemas modernos com dezenas de gigabytes de memória e armazenamento relativamente rápido de SAN e SSD, mas ainda importa. Se algum analista executar uma consulta massiva de varredura de tabela no banco de dados OLTP, que elimina metade do cache do buffer, as consultas eficientes em armazenamento permitirão que você recupere a velocidade mais rapidamente.
DBCC FLUSHPROCINDBOcorreu um erro ao executar : Um número incorreto de parâmetros foi fornecido à instrução DBCC.