Щойно я дізнався, що компанія-клієнт, над якою працюю, вирішила відключити параметри статистики автоматичного оновлення для деяких своїх SQL-серверів, а DBA вручну усунути проблеми з продуктивністю, коли вони виникають.
Однак такий спосіб для мене не має сенсу. Чому ви хочете не допустити оновлення статистики?
Відповіді:
Моя порада:
sp_updatestatsоновить всі статистичні дані для всіх таблиць у базі даних для вас, але це також спричинить збережені перекомпіляції протоколу, тому вибирайте свій час ретельно (тобто sp_updatestatsбезпосередньо перед звітом про кінець місяця, ймовірно, неоптимальним).Скільки часто потрібно запускати статистику обслуговування / відновлення індексу, залежить від завантаження вашої бази даних, зокрема від того, як часто ваші дані змінюються (тобто INSERT// UPDATE/ DELETE). Якщо ви змінюєте дані протягом усього шоу (тобто таблиця постановок для щотижневого пакетного процесу), ви, ймовірно, хочете щодня оновлювати статистику / реорганізовувати індекси. Якщо ваші дані досить статичні, ви, ймовірно, можете складати це щотижневий або щотижневий графік.
Я бачив це лише один раз із поганим додатком, який мав погано індексовану купу і мав важкі ETL.
Це сміття і, на щастя, не моє.
Інакше причин немає.
Якщо ви отримуєте оновлення статистики у невідповідний час, це означає, що ви виконуєте неправильне обслуговування індексу / статистики або маєте масивні видалення / завантаження, які досягли порогу.
За допомогою SQL Server 2005+ ви можете будь-коли відкласти оновлення статистики.
Див. "Коли використовувати оновлення синхронної чи асинхронної статистики"
Було б цікаво подивитися, яку статтю вони дотримувались чи читали, щоб зробити цей вибір ...
За старих часів (SQL Server 2000) встановлення статистики автоматичного оновлення може призвести до великих «пауз» у програмах OLTP, коли SQL вирішив зробити оновлення статистики.
Від SQL Server 2005 і далі існує асинхронна опція, яка не призведе до "паузи", коли статистика застаріла і згодом перекомпілюється. Статистика буде перекомпільована асинхронно наступного разу, коли буде потрібно.
Майте на увазі, що має бути баланс - для великих наборів даних, можливо, ви хочете, щоб поточний запит враховував найновішу статистику, оскільки запит може тривати експоненціально довше за неефективного плану запитів.
Ви також можете відстежувати кількість перекомпіляцій в секунду та інші важливі показники продуктивності, використовуючи лічильники perfmon , які публікуються SQL Server, як кажуть, докази є в пудингу.
Наскільки активні системи?
Якщо вони здебільшого читають системи, які ви можете отримати, не оновлюючи їх, якщо вони трапляються вручну під час зміни даних (вставлення, оновлення, видалення).
Однак для найкращої практики рекомендується дотримуватися справи, я думаю, що це буде рідкістю, щоб це було питанням ефективності. Я, мабуть, надішлю їм статті та дописи в блозі, в яких пропонується залишити його. У Кімберлі Тріпп є кілька хороших.
Хоча я ніколи ні в якому разі не суперечую чи навмисно не розважаю містера Денні (надто поважаю його знання та внесок у співтовариство), я помітив документацію щодо MS, яка рекомендує вимкнути статистику автоматичного оновлення.
У плануванні та конфігурації ємностей для зберігання та SQL Server (SharePoint Server 2010) MS рекомендує відключити його.
Я також читав ту саму рекомендацію MS для більш ранніх версій SP, але зараз не можу знайти посилання.
Але я НЕ DBA експерта з SP, тому ви, можливо, також захочете перевірити, що Чун Лю, MS Permier Field Engineer, повинен сказати про це в Чун Лю на SharePoint або просто проігнорувати цю публікацію та залишити її.
Зазвичай ви вимикаєте їх лише у тому випадку, якщо у вас є спосіб їх оновлення самостійно. Я роблю це постійно, оскільки нам потрібен кращий або просто інший вибірки, ніж це робитиме автоматична статистика. Це досить поширене явище, але ви б просто не вимкнули його і не зробили нічого іншого.