Плани відтворення SQL Server щодня


14

У нас є ця проблема у виробничому середовищі.

Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) - Enterprise Edition (64-розрядна) для Windows NT 6.1 (Build 7601: Service Pack 1).

SQL Server скидає всі (майже на 100%) старі плани виконання та відтворює їх щодня протягом ночі (з 23:00 до 8:00 ранку). Це траплялося навіть тоді, коли "статистика автоматичного оновлення" була у відключеному стані. Ми вмикали "статистику автоматичного оновлення" протягом останніх 2-3 тижнів. Але це все одно відбувається.

Ми насправді не знаємо, що викликає це поновлення планів, але ми впевнені, що не робимо це вручну.

Єдине, що насправді збігається з термінами відновлення планів - це робота з обслуговування БД, яку ми маємо: щоденна реорганізація індексу (коли фрагментація становить 5-30%) та щоденна перебудова індексу (коли фрагментація перевищує 30% ) робота. Зазвичай ця щоденна робота з технічного обслуговування здійснює лише реорганізацію (оскільки фрагментація індексу ніколи не перевищує 30% щоденно).

Вплив:

Ці новостворені плани змушують деякі дзвінки / запити UDF (які викликаються з UI / веб-сторінок) займають більше часу (хвилин на відміну від менше 1 секунди), і тому сеанси просто накопичуються, приймаючи процесор близько 90% .

Проблема знімається з того моменту, коли ці застряглі сеанси насильно видаляються (на стороні БД) та 1), коли всі відповідні плани виконання очищаються вручну (для запитів) або 2) при зміні UDF (для функцій). Будь-які нові плани, створені SQL-сервером з цього моменту, працюють просто ідеально протягом усього дня, поки вранці не виникне та сама проблема. Крім того, така поведінка не на 100% послідовна, ми насправді не бачимо її щоранку. Але були періоди часу, коли ми спостерігаємо це послідовно 4-5 днів поспіль.

Проблема трапляється вранці, тому, коли користувачі інтерфейсу / веб-сторінки доступні більш інтенсивно, схоже.

Хтось має підказку, що це викликає, і як вирішити цю проблему? Будь-яка допомога буде дуже вдячна.


3
планувальний кеш може бути звільнений або коли машина знаходиться під тиском пам'яті, або якщо ви зміните налаштування на рівні d db. (alter db). Оскільки ви сказали, що не видаляєте їх "вручну", я припускаю, що це може бути тиск у пам'яті. Скільки пам’яті має машина? які налаштування вашої максимальної пам'яті? у вас віртуальне середовище і, можливо, перерозподілена оперативна пам’ять?
RayofCommand

6
Чому ти на SP1. Перш ніж робити будь-яку річ, застосуйте SP3. SQL Server може змусити планувати, якщо він знаходить тиск у пам'яті та потребує більше пам’яті для розміщення сторінок спеціально з індексної перебудови, особливо якщо у вас є великі таблиці. Поновлення індексу спробувало б принести якомога більше сторінки. Що ви можете зробити, це припинити використання MP та використовувати рішення Ola Hallengren і подивитися, чи це допомагає. Що таке максимальна пам'ять сервера?
Шанки

1
Хлопці, я не DBA, лише розробник SQL. Я просто запитую все це, як це триває вже досить довго. Дякую за ваші коментарі, я спробую відповісти на всі вони, хоча наразі мені важко слідкувати (і все це здається вам досить очевидним). Що таке МП?
peter.petrov

1
@ peter.petrov ми намагаємось допомогти вам, ознайомившись із своїм оточенням. MP = Плани технічного обслуговування.
Кін Шах

1
Справжня проблема полягає в тому, що ваші плани запитів настільки крихкі. Репіляції можуть відбуватися в будь-який час, навіть протягом дня. Ніяких гарантій. Виправте свої запити, щоб плани стали стабільними. РЕКОМПЛІЯ ОПЦІЇ або ОПТИМІЗУВАННЯ ДЛЯ НЕЗАЄМОГО - це підходи кувалди, які можуть бути відповідними та швидко виправити.
usr

Відповіді:


2

Ну, я маю кілька ідей, які можуть викликати таку поведінку.

  1. Ви контролюєте тиск пам'яті? Можливо, ваші запити підвищують певний ліміт, який спричинить змивання кешу плану. Я не знаю вашої заявки, але чи відповідає цей кореспондент вашими журналами з ваших прифронтових серверів? Чи є тиск теж за цей час?
  2. У вас є виділений SQL Server або сервер ділиться його обладнанням з іншими процесами / послугами? Якщо ні, спробуйте передати ваш сервер SQL на спеціальну машину. Це зменшить побічні ефекти від інших служб.
  3. Ви можете скористатися optimize for ad hoc workloads, що просто збереже заглушку плану та складе його, якщо це потрібно. Це зменшить навантаження вашого планкешу, що знизить ймовірність промивання. Ви можете ввімкнути це за допомогою sp_configure 'optimize for ad hoc workloads',1; reconfigure. Це можна зробити, якщо ви ввімкнули advanced optionsвикористання sp_configure 'show advanced options',1; reconfigure.
  4. Ще однією ідеєю можуть бути резервні копії. Просто прості резервні копії. Якщо вони агресивно, може статися, що машина також зазнає тиску. Час, коли ви згадуєте, просто звучить як хороший проміжок часу для планування резервного копіювання.
  5. Можливо, це досить проста помилка у вашому сценарії обслуговування. Ви перевірили, чи є логічна проблема, яка змушує ваш скрипт перебудувати всі індекси замість лише тих, які відповідають критеріям. Це, можливо, може спричинити і це.

Просто у всіх цих можливостей, це може бути корисно перевірити лог - файли для деяких змін параметрів affinity mask, affinity I/O maskі їх партнерів 64. Інша справа може бути зміною MAXDOPопції вашого примірника. Будь ласка, перевірте журнали і для них. Їм також потрібно буде змити планкеш.

І останнє, але не менш важливе, ви все ще можете запустити трасування на сервері (просто встановивши його за допомогою профайлера, запустити його, зупинити його і за допомогою команди sql запустити його знову на сервері). Поруч із цим perfmonтвій друг. Він може переглядати та контролювати ваші показники продуктивності протягом певного часу. Можливо, ви можете побачити паралелі тиску з певними діями на вашому сервері, які можуть спричинити цей флеш.

Сподіваємось, це допоможе вам, навіть якщо відповідь надійде трохи пізніше.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.