Чому встановити статистику автоматичного оновлення на помилкову?

Я щойно успадкував близько 20 екземплярів SQL Server, як частина більш широкого проекту придбання. Я перебуваю в процесі оцінки продуктивності, і мені не подобається, як були виконані плани технічного обслуговування.

Я бачу щоденні перебудови індексу ковдри (я можу з цим впоратися), а також щоденне ручне оновлення статистики.

Близько половини баз даних було встановлено на автоматичне оновлення статистики = помилкове, з причин, які не зрозумілі, крім того, як мені кажуть, це зменшити "Проблеми з продуктивністю" ...

Я завжди думав і працював над найкращою практикою встановити це значення True і вважав, що ручне оновлення не є необхідним, якщо цей параметр був істинним. Я помиляюся?

Чи може хто-небудь пояснити, яка користь була б від того, щоб цей набір був помилковим, але робити щоденне оновлення вручну?

Слід зазначити, що деякі бази даних є дуже транзакційними (мільйони вкладок, видалення, оновлень на день). Інші мають низький показник трансакційних ставок, а деякі - лише для читання. Немає жодної рифми чи причини, хоча для параметра Автоматичне оновлення встановлено значення False. Здається, це лотерея.

Ви вірні, я також вважаю, що в більшості випадків Auto Update statisticsслід встановити значення true, ми повинні дозволити SQL Server вирішувати, коли оновлювати статистику, і повірте мені, що це робить добре. Коли для цього встановлено значення true, переконайтеся, що статистику поновлено щодо розподілу даних у цій галузі, що в кінцевому підсумку допоможе оптимізатору підготувати кращий план. Тут важливо зазначити, що автоматичне оновлення статистики запускається, коли в таблиці змінюється 20% даних. Тож ви не повинні відчувати, що на таблиці зі 100-рядковими рядами, якщо оновлено 10 рядків, тоді оновлення стану запуститься.

Більш глибокий аналіз робить Пол Рандал у блозі Розуміння, коли статистика автоматично оновлюватиметься . Я не бачив жодного недоліку, якщо для цього параметра встановлено значення true. Так, ви можете бачити деяку активність вводу-виводу, коли для цього параметра встановлено значення true.

Важливий висновок, який можна зробити із блогу

Навіть якщо статистика застаріла в результаті модифікації, вона не буде автоматично оновлюватися після завершення модифікації. Статистика автоматично оновлюватиметься наступного разу, коли план запитів використовуватиме його.

У випадках, коли ви щойно читали тільки бази даних або бази даних, де ви просто виконуєте операцію вибору, і немає операції DML, у такому випадку ви можете зберегти параметр false, але знову не буде шкоди, якщо ви збережете його правдою. Ми в основному бачимо базу даних з певним рівнем активності.

Це занадто довго для коментарів, тому я підкажу інший випадок, коли, можливо, потрібно вимкнути статистику автоматичного оновлення. Я працював з базами даних, що підтримують об'ємні навантаження OLTP та суворий рівень довіри SLA для виконання запитів у мілісекундах. Майже всі запити були тривіальними з великою увагою до деталей налаштування запитів та індексів, а деякі таблиці були досить великими. У цій ситуації не було великого значення для оновлення статистики протягом пікових періодів, а статистика автоматичного оновлення порушила б угода про домовленості. Отже, технічне обслуговування здійснювалось у не пікові періоди через заплановану роботу.

Ще один варіант - ввімкнути AUTO_UPDATE_STATISTICSі AUTO_UPDATE_STATISTICS_ASYNCпараметри, і параметри бази даних. Це дозволить запитам виконувати плани виконання на основі статистики несвіжих, а не здійснювати накладні витрати на оновлення статистики синхронно. Це особливо доречно для навантаження OLTP, якщо сервер має розмір для розміщення навантаження на запит плюс оновлення фонової статистики.

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

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

У вас також можуть бути сценарії, коли ви оновлюєте дані кілька разів протягом дня, але не обов’язково оновлювати статистику після кожного оновлення. (Скажімо, дані запитуються лише в певні години дня - не потрібно оновлювати статистику кілька разів, коли дані тим часом не будуть запитуватися.)

А може, у вас просто навантаження велика. Або показання, як правило, є повним скануванням, де статистика не є надзвичайно важливою.