Окончательный список шагов для базового тестирования SQL Server?

Question

Перед запуском тестирования / базовой линии производительности для приложения, которое использует SQL Server, я хочу иметь возможность установить экземпляр в «чистое» состояние, не перезагружая экземпляр. Есть шаги, которые я склонен следую, но я хочу составить окончательный список, который находится в правильной последовательности и не имеет избыточных шагов.

Дополняет ли этот список шагов настройку SQL Server в «чистое» состояние?

Последовательность логична / правильная?

Есть ли избыточные шаги?

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!'

Answer 1

Во -первых, я бы отступил и спросил, какие измерения вы планируете собирать во время теста. Например, если вы считаете логические чтения по запросу, то вам не нужно освобождать кэш. Я большой поклонник использования логических чтений, потому что он не зависит от того, кэшируются ли данные или на диске - и в производстве трудно догадаться, будут ли данные запроса кэшированы или нет (если вы не кешите всю базу данных в памяти) Анкет Если вы настраиваете, чтобы минимизировать логические чтения, то приложение пойдет быстрее, независимо от того, есть ли данные в кэше или нет.

Далее я бы спросил, что меняется между пробежками. Например, запустив EXEC SP_UPDateStats в каждой базе данных, как вы предложили, вы собираетесь повторно принять статистику для обновления таблиц. Однако, если вы не обновляете статистику с помощью FullScan, вы получаете случайные строки из таблицы - это не слишком повторяется, и я не думаю, что вы действительно хотите это сделать. Вместо этого вы можете восстановить базы данных между каждым запуском, чтобы вы всегда тестировали точно одинаковые данные. Если ваши тесты выполняют вставки/обновления/удаления, у них могут быть разные профили производительности при каждом пробеге, если вы не восстанавливаете базу данных (потому что они добавляют/изменяют данные, а также изменяют статистику на данные) - и, что еще хуже, Вы могли бы иметь вопросы, если они попытаются вставить повторные данные для тех же значений.