Остаточний перелік етапів тестування базової лінії SQL Server?

Перш ніж запустити тест / базову лінію для програми, що використовує 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!'

— Ерік Хіггінс
джерело

FYI, DROPCLEANBUFFERSце приємно для тестування, але не завжди точно. Якщо ви посилаєтесь на таблицю з великим обсягом, дуже ймовірно, у вас майже завжди будуть сторінки в пам'яті, а час введення-виводу не буде великим фактором у цьому запиті. Ви можете надати більше ваги на IO, ніж це реально в цьому випадку.

— JNK

Ви говорите про тестування у виробничому середовищі чи ізольованому тестовому середовищі?

— bopapa_1979

Усі, хто тестує в середовищі Prod, повинні бути звільнені. :) Так, тестові середовища.

— Ерік Хіггінс

Спочатку я б відступив і запитав, які вимірювання ви плануєте зібрати під час тесту. Наприклад, якщо ви підраховуєте логічні зчитування за запитом, вам не потрібно звільняти кеш. Я великий прихильник використання логічних зчитувань, тому що це незалежно від того, кешировано чи на диску дані, і у виробництві важко здогадатися, буде чи кешировано дані запиту чи ні (якщо ви не кешуєте всю базу даних в пам'яті) . Якщо ви налаштуєте мінімізувати логічні зчитування, програма перейде швидше, чи є дані в кеші чи ні.

Далі я б запитав, що змінюється між прогонами. Наприклад, запустивши EXEC SP_UPDATESTATS у кожній базі даних, як ви запропонували, ви збираєтеся перепробовувати статистику для оновлених таблиць. Однак, якщо ви не оновлюєте статистику за допомогою повного скану, ви отримуєте випадкові рядки з таблиці - це не надто повторюється, і я не думаю, що ви дійсно цього хочете робити. Натомість, можливо, ви захочете відновити бази даних між кожним запуском, щоб ви завжди тестували абсолютно однакові дані. Якщо ваші тести роблять вставки / оновлення / видалення, вони можуть мати різні профілі продуктивності на кожному запуску, якщо ви не відновлюєте базу даних (тому що вони додають / змінюють дані, а також змінюють статистику даних) - і ще гірше,

— Брент Озар
джерело

Дуже хороші очки, мета - щоб все було однакове між пробіжками. Вимірювання, які я беру в цьому випадку @ hand, - це час запуску для певних функцій програми (x секунд для повернення списку до програми, y секунд для додавання елемента черги тощо). Зміни між тестами можуть бути фрагментами коду програми, а не об'єктами SQL, об'єктами SQL, а не кодом програми, або налаштуваннями рівня екземпляра / БД, такими як паралельність без змін коду програми. Якщо я хотів би додати відновлення поза воротами перед кожним тестом, як ви ставитесь до мого списку вище @ цього пункту? Я щось пропускаю, чи послідовність потребує певної роботи?

— Ерік Хіггінс

Brent, ти враховуєш CPU під час тестування?

— АК

@EricHiggins Замість того, щоб перевіряти кілька речей одночасно, я б протестував деталі окремо. Я б краще перевірити запити безпосередньо і побачити, що зміни впливають на продуктивність. Наприклад, запустіть SQL-слід, виконуючи певні функції в додатку, а потім продовжуйте відтворювати цей слід, вносячи зміни в індексі / конфігурації для поліпшення продуктивності, а також спостерігайте за такими речами, як логічні зчитування та показники процесора, у слідах.

— Брент Озар

@AlexKuznetsov Насправді я не той, хто робить тестування - Ерік - це той, хто задав питання. Коли я займаюся подібною роботою, я дивлюся на показники процесора на рівні запитів, а також на загальний сервер.

— Брент Озар

Ми використовуємо сторонній генератор навантажень (і працюємо штатним персоналом, присвяченим розробці навантажувальних тестів). Тож мої тести точні до транзакції, послідовності, кількості користувачів, точних кроків, виконаних у додатку ... все. Тому мені не обов’язково взагалі дивитися на метрику типу інформаційної панелі SQL. Програмне забезпечення для тестування навантаження відстежує час відгуку модулів програми до мілісекунди. Отже, відновлення БД - хороша ідея. Мені потрібно з розумом перевірити інші кроки, які я роблю, щоб бути впевненим, що я домагаюся того стану «Чистий сланцевий», якого я шукаю перед кожним раундом тестування.

— Ерік Хіггінс