Як відповісти, чому раптом нам потрібні індекси чи запити, потрібно змінити

Я молодший DBA з 3-річним стажем. Наша робота полягає в тому, щоб налагодити запити або порадити розробникам, що конкретний код повинен бути переписаний або потрібні індекси.

Одне просте запитання, яке задає команда розробників, часто: "Вчора це нормально пройшло, що змінилося раптом?" і нас попросять перевірити інфраструктурну сторону. Першою реакцією на будь-яку проблему завжди видається максимум вини в інфраструктурі, яка завжди перше, що перевіряється.

Як нам відповісти на питання "що змінилося" командою розробників? Ви коли-небудь стикалися з тією ж ситуацією? Якщо так, будь ласка, поділіться своїм досвідом.

Як відповісти на те, що змінило запитання від розробника?

Це дуже поширене питання не тільки для DEV, воно стосується кожної команди в галузі ІТ та бізнесу.

Що змінилося? ==> можна відповісти фактами та цифрами.

Факти посилаються, наприклад

• збільшити кількість користувачів, які отримують доступ до бази даних?
• Будь-яка зміна параметра налаштування сервера?
• Обслуговування баз даних - статистика оновлення, реорганізація / відновлення індексів не виконується? Завдяки цьому плани генеруються неправильно!
• Обсяг даних збільшився?
• Були внесені зміни на мережевій стороні, ОС було виправлено і / або розгорнуто новий пакет оновлень або CU для sql-сервера - не роблячи повного тестування регресії бізнес-циклу вашої програми ?
• Основний SAN став раптово повільним?

Цифри можна отримати, якщо у вас є дані для показу. Наприклад :

• Під час цієї ситуації важливе значення має базове налаштування вашого сервера. Це полегшить гру звинувачення, оскільки ви можете підтримати факти твердими цифрами.
• Почніть збирати дані за допомогою DMV або sp_whoisactive до таблиці, щоб дані зберігалися після перезавантаження сервера sql.

(Ви повинні тренуватися залежно від вашого середовища та потреб, від того, як часто збирати дані / які дані збирати і скільки буде тримати період зберігання) або (Ви можете інвестувати в програмне забезпечення сторонніх виробників, наприклад, sqlsentry або діагностичний менеджер Idera, що зробить вищезгадану роботу за вас) .

Ну, ви могли б отримати інший план, тому що:

• план міг бути виселений із кешу через:
  • перезапуск служби
  • ручне очищення кешу плану
  • перезапуск служби або відмова від служби
  • ненавмисна зміна, наприклад, певні sp_configureзміни можуть змити кеш
  • деяка зміна основних об'єктів, індексів, статистичних даних або інших залежностей викликала перекомпіляцію
• ви можете просто отримати інший план, ніж інші користувачі або попередні виклики, оскільки:
  • текст запиту може бути не ідентичним (це включає чутливість регістру та пробіл, незважаючи на різні стовпці, критерії приєднання, фільтри тощо)
  • запит може виконуватися різними користувачами з різними параметрами набору (або різними схемами за замовчуванням, якщо будь-який об’єкт у плані не має повноцінного імені, включаючи схему )
• запит і план можуть бути однаковими, але ви можете отримати різну ефективність, оскільки:
  • план був кешований з використанням різних параметрів, і цей план не є оптимальним для поточного набору параметрів (це зазвичай називається "нюхання параметра")
  • кількість даних на основі параметрів або просто за рахунок зміни даних тим часом значно відрізняється
  • дані досить змінені, щоб змінити найефективніший спосіб доступу до даних, але недостатньо для запуску оновлень статистики або перекомпіляцій (пошук ключової проблеми, а також алгоритм автоматичної статистики)
  • дані були вилучені з буферного пулу, і тепер їх потрібно читати з диска
  • існує більша паралельність, блокування або інші труднощі з ресурсами, необхідними для задоволення запиту

Я детальніше переглядаю багато з них більш докладно тут:

• Кілька планів для "ідентичного" запиту

Якщо вони працюють у різних середовищах, я маю перевірити тут цілу низку речей:

• Різні плани для "ідентичних" серверів

Також важливо пам’ятати, що створення індексу або зміна запиту може бути не прямою причиною, що запит раптом працює краще - іноді це просто тому, що ці зміни справді створили новий план та / або визнали недійсним той, який вже існував .

Як завжди, Аарон Бертран і Кін дали чудові відповіді. Однак обидві відповіді містять загальну нитку. Якщо проаналізувати будь-яку відповідь, ви побачите, що причина, чому XYZ не працює так, як це працювало вчора, не через те, що ви / вони / людина X зробили. Причина, чому змінилися речі, полягає в тому, що база даних вирішила зробити інакше через причини XYZ.

База даних - це жива, дихаюча сутність . Бази даних прийматимуть рішення та змінюватимуть свою думку завдяки комбінації припущень, статистики та інших евристичних інструментів. Це кардинально відрізняється від більшості програм програмування шарів (помітним винятком є ​​машинне навчання).

_{Я буду використовувати деякі військові довідки, тому що я не можу придумати щось краще зараз. Буде вдячна більш загальна метафора (жоден каламбур).}

У більшості застосувань програміст виступає інструктором свердління. Вони кажуть комп’ютеру , що саме робити, в якому порядку, а іноді і на скільки часу. Програмування бази даних більше схоже на роль командира. Ви кажете йому, що ви хочете, щоб це робило на високому рівні, і пропонуєте певні рекомендації там, де це потрібно. База даних бере на себе завдання з'ясування найкращого способу виконання плану на основі поточної розвідки, наприклад, молодших офіцерів та унтер-офіцерів.

Зрозумівши це розрізнення у свідомості інших програмістів, вони, сподіваємось, почнуть бачити, що ви не маєте дикторських повноважень, як вони роблять над своїм оточенням. Ви орієнтуєтесь на базу даних до рішення, а час від часу база даних виходить з добрих чи поганих причин. Нагадайте їм, що врешті-решт не важливо, чому * база даних пішла з шляху, а що ми можемо зробити, щоб повернути її.

_{* Я усвідомлюю, що "чому" є дуже цінним для подальшої профілактики, навчання тощо, але здається, що ОП наштовхується на опір людей, які не намагаються дізнатися про проблему чи допомогти їй.}