Доцільність використання STATISTICS_NORECOMPUTE

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

Коли я порівнював тестові та модельні середовища, я помітив, що більшість індексів у модельному середовищі STATISTICS_NORECOMPUTEвстановлено на ONтой час, як тестові. У всіх середовищах є щонічна робота, яка оновлює статистику всіх баз даних.

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

EDIT: Я знайшов один з блогів Kimberly Tripp з даного питання тут , що , здається, припустити , що STATISTICS_NORECOMPUTEслід використовувати з обережністю в кращому випадку . Але я все ще стурбований тим, щоб вимкнути це глобально. Хтось пробував це і що вони відчували?

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

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

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

Думаючи про це більше, я скажу, що поточна стратегія має сенс. Це краще, ніж залишати статистику автоматичного оновлення для всього? Здається, хтось так подумав, до того, що варто було простоти управління компрометацією асоційованої роботи з агентом SQL.

Якщо ідея полягала в тому, щоб мати доступні свіжі статистичні дані без блокування запитів (наприклад, це ), ви можете розглянути можливість увімкнення автоматичного оновлення для всього, а потім також увімкнути його AUTO_UPDATE_STATISTICS_ASYNC. Тоді, можливо, змініть графік роботи, щоб він працював один раз на тиждень, а не щодня, оскільки ви все ще хочете WITH FULLSCANперіодично оновлюватись .

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