Antes de executar um teste de desempenho/linha de base para um aplicativo que usa o SQL Server, quero poder definir a instância para um estado "limpo", sem reiniciar a instância. Há etapas que costumo seguir, mas quero criar uma lista definitiva que esteja na sequência correta e não tenha etapas redundantes.
Esta lista de etapas realiza a configuração do SQL Server para um estado "limpo"?
A sequência é lógica/correta?
Existem etapas redundantes?
CHECKPOINT -- Write all dirty pages
DBCC DROPCLEANBUFFERS -- All should be clean after checkpoint?
DBCC FREEPROCCACHE -- Clear the plan cache
DBCC FREESYSTEMCACHE -- Is this necessary after FREEPROCCACHE?
DBCC FREESESSIONCACHE -- May not be necessary if distributed queries aren't used, but want to catch all scenarios
EXEC SP_UPDATESTATS -- Refresh stats
'BEGIN TESTING!'
Primeiro, eu daria um passo para trás e perguntaria quais medições você planeja coletar durante o teste. Se você estiver contando leituras lógicas por consulta, por exemplo, não precisará liberar o cache. Sou um grande fã do uso de leituras lógicas porque independe se os dados estão em cache ou em disco - e na produção, é difícil adivinhar se os dados de uma consulta serão armazenados em cache ou não (a menos que você armazene em cache todo o banco de dados na memória) . Se você ajustar para minimizar as leituras lógicas, o aplicativo será mais rápido, quer os dados estejam no cache ou não.
Em seguida, eu questionaria o que está mudando entre as execuções. Por exemplo, ao executar EXEC SP_UPDATESTATS em cada banco de dados conforme sugerido, você fará uma nova amostra das estatísticas das tabelas que foram atualizadas. No entanto, a menos que você esteja atualizando as estatísticas com fullscan, você está obtendo linhas aleatórias da tabela - isso não é muito repetível e não acho que você realmente queira fazer isso. Em vez disso, talvez você queira restaurar os bancos de dados entre cada execução para testar sempre exatamente os mesmos dados. Se seus testes estão fazendo inserções/atualizações/exclusões, eles podem ter diferentes perfis de desempenho em cada execução se você não estiver restaurando o banco de dados (porque eles estão adicionando/alterando dados, além de alterar estatísticas nos dados) - e pior ainda,