Актуализации на статистиката

Последните няколко издания на SQL Server въведоха множество нови функции, както и подобрения в съществуващата функционалност. Една област на двигателя, която е лесна за пренебрегване, е статистиката. В крайна сметка статистическите данни все още се създават по същия начин, те все още ви разказват за разпределението на данни, все още се използват от оптимизатора на заявки... какво е различното? Основната функция на статистическите данни остава същата – но начинът, по който те се използват от оптимизатора на заявки, се променя в зависимост от кардиналния оценител, който използвате. Има и няколко забележителни промени, свързани с актуализирането на статистическите данни и е добавена нова функционалност около прегледа на статистическа информация. Като цяло тези промени в най-новите версии могат да причинят вариация в поведението на SQL Server, която не сте очаквали.

Забележка:Тази публикация е най-приложима за SQL Server 2012 и по-нови версии, но някои подробности за предишни версии са включени за справка (и забавление).

SQL Server 7.0

Броят на стъпките в хистограмата е ограничен до 300. В SQL Server 6.5 и по-стари хистограмата ще има броя стъпки, които биха могли да се поберат на 2K страница, въз основа на размера на първата колона в ключа.
Въведена е опцията за база данни „автоматично актуализиране на статистическите данни“; по-рано статистическите данни бяха актуализирани само ръчно.

SQL Server 2000

Броят на стъпките в хистограмата се намалява от 300 на 200 (технически 201, ако включите стъпката за NULL, като приемем, че първата колона в ключа позволява NULL).

SQL Server 2005

Актуализациите на статистическите данни, които използват FULLSCAN, могат да се изпълняват паралелно.
Флаговете за проследяване 2389 и 2390 са въведени в SP1, за да помогнат при проблема с възходящия ключ, описан в публикацията, Възходящи ключове и статистики за автоматична бърза корекция. Подробен пример за този сценарий е предоставен в моя публикация Trace Flag 2389 и новият оценител на кардиналността.
Въведена е опцията на екземпляра „Автоматично актуализиране на статистическите данни асинхронно“. Имайте предвид, че за да бъде това в сила, опцията „Автоматично актуализиране на статистиката“ също трябва да бъде активирана. Ако не сте наясно какво прави тази опция, прегледайте документацията в ALTER DATABASE SET Options. Това е настройка, която Глен препоръчва (както е отбелязано в неговата публикация, посочена по-долу), но мисля, че е важно да сте наясно с потенциалните проблеми, както е отбелязано в Как автоматичните актуализации на статистиката могат да повлияят на производителността на заявката.

Забележка: Има изтичане на памет, свързано с тази настройка в SQL Server 2008 до SQL Server 2012; моля, вижте публикацията на Glenn Важна актуална корекция за SQL Server 2008 за повече подробности.

SQL Server 2008

Въведени са филтрирани статистически данни, които могат да бъдат създадени отделно от филтриран индекс. Има някои ограничения около филтрираните индекси по отношение на публикацията на оптимизатора на заявки (вижте публикацията на Тим Чапман The Pains of Filtered Indexes и публикацията на Paul White, Optimizer Limitations with Filtered Indexes) и е важно да разберете поведението на брояча, който проследява модификациите (и по този начин може да задейства автоматични актуализации). Вижте публикацията на Кимбърли Филтрираните индекси и филтрираните статистики може да станат сериозно остарели за повече подробности, а също така препоръчвам да проверите нейната съхранена процедура, която анализира изкривяването на данните и препоръчва къде можете да създадете филтрирани статистически данни, за да предоставите повече информация на оптимизатора на заявки. Внедрих това за няколко големи клиенти, които имат VLT и изкривено разпределение в колони, често използвани в предикати.
Два нови каталожни изгледа, sys.stats и sys.stats_columns, са добавени, за да осигурят по-лесна представа за статистическите данни и включени колони. Използвайте тези два изгледа вместо sp_helpstats, който е остарял и предоставя по-малко информация.

SQL Server 2008R2 SP1

Представя се Trace Flag 2371, който може да се използва за намаляване на броя на модификациите, необходими за извършване на автоматични актуализации на статистиката. Като напомняне, аз съм фен на редовното актуализиране на статистическите данни чрез планирана работа и оставянето на автоматичната актуализация активирана като безопасност.

SQL Server 2008R2 SP2

Включена е функцията sys.dm_db_stats_properties, която предоставя същата информация, която се намира в заглавката на DBCC SHOW_STATISTICS, както и колона за модификация, която може да се използва за проследяване на промените и програмно определяне дали е необходима актуализация. Помните ли предпочитанията ми за използване на работа за актуализиране на статистика? Тази работа току-що стана много по-интелигентна с този DMF...сега мога да видя колко данни са били променени и САМО да актуализирам статистиката, ако определен процент от данните се е променил. Гласък.

SQL Server 2012

Актуализирането на статистическите данни няма да доведе до анулиране на планове, АКО няма променени редове. Това изненадва много хора и Кимбърли има забавна публикация „Какво накара този план да се обърка – трябва ли да актуализирате статистическите данни?“, която минава през приключението си, за да разбере това.

SQL Server 2012 SP1

DBCC SHOW_STATISTICS изисква само разрешение SELECT – преди това изискваше потребител да бъде член на sysadmin или член на ролята на db_owner или db_ddladmin. Това може да бъде глобално деактивирано с флаг за проследяване 9485.
Включва sys.dm_db_stats_properties (вижте бележката за 2008R2 SP2 по-горе)

SQL Server 2012 SP2

Кумулативната актуализация 1 въвежда корекция, свързана с възходящите ключове, които не са правилно идентифицирани дори при използвани флагове за проследяване 2389 и 2390. Това изисква флаг за проследяване 4139 в допълнение към CU1, както е отбелязано в KB 2952101.

SQL Server 2014

Въвежда се новият Cardinality Estimator, реализиран чрез задаване на режима за съвместимост на базата данни на 120 или чрез използване на флаг за проследяване 2312. Ако не сте чели нищо за новия CE, препоръчвам да започнете с документацията за оценка на кардиналността и след това да прочетете Joe Бялата книга на Sack, Оптимизиране на вашите планове за заявка с SQL Server 2014 Cardinality Estimator, за задълбочени подробности.
Поведението от Trace Flags 2389 и 2390 за възходящи ключове вече се реализира чрез режима за съвместимост на базата данни. Ако режимът на съвместимост на вашите бази данни е настроен на 120 (или по-високо в по-късни версии), не е необходимо да използвате Trace Flags 2389 и 2390 за SQL Server, за да идентифицирате статистики, които имат възходящи ключове.
Инкременталните статистически данни са въведени за дяловете и могат да бъдат прегледани чрез новия DMF sys.dm_db_incremental_stats_properties. Инкременталните статистически данни предоставят начин за актуализиране на статистически данни за дял, без да ги актуализирате за цялата таблица. Допълнителната статистическа информация от инкременталната статистика обаче не се използва от оптимизатора на заявки, а се сгъва в основната хистограма за таблицата.
CU2 включва същата поправка, спомената по-горе за SQL Server 2012 SP2, която също изисква флаг за проследяване 4139.

SQL Server 2014 SP1

Флагът за проследяване 7471 е обратно пренесен към CU6, първоначално наличен в SQL Server 2016, както е отбелязано по-долу.

SQL Server 2016

Флагът за проследяване 2371 вече не е необходим за намаляване на прага за автоматични актуализации на статистиката, ако режимът на съвместимост на базата данни е настроен на 130. Вижте Управление на поведението на автостат (AUTO_UPDATE_STATISTICS) в SQL Server.
Актуализациите на статистическите данни могат да се изпълняват паралелно, когато използвате SAMPLE, а не само FULLSCAN. Това е свързано с режима на съвместимост (трябва да е 130), но потенциално може да осигури по-бързи актуализации и по този начин да намали прозорците за поддръжка. Аарон Бертран говори за това подобрение в публикацията си, Потенциално подобрение за актуализации на статистиката:MAXDOP.
Флагът за проследяване 7471 е въведен в CU1, за да позволи на няколко команди UPDATE STATISTICS да се изпълняват едновременно за една таблица и Джонатан предоставя някои страхотни примери за това как това може да се използва в публикацията си Подобрена поддръжка за възстановяване на паралелни статистики.

SQL Server 2016 SP1

Въвежда се опцията за намек за заявка ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS, заедно с аргумента FOR HINT, който е еквивалент на флаг за проследяване 4139.
DMF sys.dm_db_stats_histogram се излага в CU2, което е алтернатива на изхода на хистограмата от DBCC SHOW_STATISTICS. Информацията и в двете е една и съща, използвайте това, което е по-лесно за вас или по-добре отговаря на проблема, който трябва да решите.
Опцията PERSIST_SAMPLE_PERCENT е въведена в CU4, която може да се използва, за да се използва една и съща честота на извадка всеки път, когато се актуализира статистически данни занапред, и примери за това поведение могат да бъдат намерени в публикацията, Постоянна честота на извадка на статистиката.

SQL Server 2017

Опцията PERSIST_SAMPLE_PERCENT е налична в CU1 (вижте запис от SP1 за 2016 г. за допълнителна информация).
Атрибутите StatsInfoType и OptimizerStatsUsageType се добавят към плана на заявката, който изброява статистически данни, използвани по време на оптимизацията на заявката. Това се предлага в CU3 и е свързано с версията CE (120 и по-висока). Това е доста готино! Все още не съм имал възможност да играя с това, но за да получите тази информация преди, трябваше да използвате недокументирани флагове за проследяване.
CU3 въведе също опцията MAXDOP за СЪЗДАВАНЕ НА СТАТИСТИКА и АКТУАЛИЗИРАНЕ НА СТАТИСТИКА, която може да се използва за отмяна на стойността на MAXDOP за модела или базата данни.
Още едно допълнение в CU3:атрибутите UdfCpuTime и UdfElapsedTime могат да бъдат намерени в плана на заявката, който представлява статистика за изпълнение на UDF със скаларна стойност.

Резюме

Ако искате да надстроите до по-нова версия или ако наскоро сте надстроили, обърнете внимание как тези промени влияят върху вашето решение. Имахме много клиенти, които се свързваха с нас след надстройка от 2005/2008/2008R2 до 2014 или 2016 г., оплаквайки се от проблеми с производителността. В много случаи адекватното тестване не е завършено преди надстройката.

Това е нещо, върху което наистина се фокусираме, когато помагаме на клиент да надгражда. Освен стъпките за преместване на производствен екземпляр от една версия в друга с малко престой, ние искаме да сме сигурни, че денят след надстройката е скучен за администраторите на база данни и разработчиците.

Ние не просто тестваме процеса на надстройка, ние тестваме как изглежда системата след надстройката. Необходими ли са същите флагове за проследяване от старата среда в новата? Какви настройки на базата данни трябва да бъдат коригирани? Променя ли се производителността на заявката – за добро или лошо? Ако не знаете отговорите на тези въпроси, преди да надстроите производството, тогава се подготвяте за един до много дни гасене на пожар, разговори в Sev 1, храна на бюрото ви, недостатъчно сън и кой знае какво още .

Отделете време предварително, за да разберете въздействието на новите функции и промените във функционалността, изброени по-горе, да планирате надстройката и да тествате колкото е възможно повече.