Antes de executar um teste de desempenho / linha de base para um aplicativo que usa o SQL Server, desejo poder definir a instância para um estado "limpo", sem reiniciar a instância. Existem etapas que eu tendem a seguir, mas quero criar uma lista definitiva que esteja na sequência correta e que 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!'
sql-server
dbcc
performance-testing
cache
Eric Higgins
fonte
fonte
DROPCLEANBUFFERSteste é bom para testar, mas nem sempre é preciso. Se você estiver referenciando uma tabela de alto volume, é muito provável que você quase sempre tenha páginas na memória, e o tempo de IO não será um grande fator nessa consulta. Você pode colocar mais peso no IO do que é realista nesse caso.Respostas:
Primeiro, eu recuaria e perguntaria quais medidas você planeja coletar durante o teste. Se você estiver contando leituras lógicas por consulta, por exemplo, não precisará liberar o cache. Sou muito fã de usar leituras lógicas porque é independente de os dados serem armazenados 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, independentemente de os dados estarem em cache ou não.
Em seguida, eu questionaria o que está mudando entre as execuções. Por exemplo, executando EXEC SP_UPDATESTATS em cada banco de dados, conforme sugerido, você vai redefinir as estatísticas das tabelas que foram atualizadas. No entanto, a menos que você esteja atualizando estatísticas com o fullscan, está obtendo linhas aleatórias da tabela - isso não é muito repetitivo, e eu não acho que você realmente queira fazer isso. Em vez disso, convém restaurar os bancos de dados entre cada execução para sempre testar exatamente os mesmos dados. Se seus testes estiverem fazendo inserções / atualizações / exclusões, eles podem ter perfis de desempenho diferentes a 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 ainda pior,
fonte