Когато създавате нова база данни в SQL Server, опцията Auto Update Statistics е активирана по подразбиране. Обикновено се препоръчва да оставите тази опция активирана. В идеалния случай статистическите данни се управляват от планирано задание, а автоматичната опция се използва като предпазна мрежа – налична за актуализиране на статистически данни в случай, че планирана актуализация не се случи или случайно не включва всички съществуващи статистически данни.
Някои DBA разчитат единствено на автоматични актуализации за управление на статистиката и стига да не съществуват проблеми с производителността, свързани с остарели или лошо извадени статистически данни, това е приемливо. Ако разчитате на тази опция за управление на вашите статистически данни и имате някои много големи таблици, може да си струва да приложите флаг за проследяване 2371. Както при всеки флаг за проследяване, уверете се, че тествате с представително работно натоварване, преди да го внедрите в производството. Може би вече сте наясно, че има моменти, когато автоматичната актуализация може да повлияе на производителността на системата. Например, актуализацията на статистика може да доведе до скок в процесора или I/O при четене на данните от таблицата или индекса, както и да забави изпълнението на заявка, докато се извърши актуализацията. Има още една опция за база данни, която можете да активирате, за да се справите със забавянето на заявката и ще разгледам това по-късно в тази публикация.
Въпросът, който често ми задават е:„Как да разберете дали автоматичните актуализации на статистиката причиняват проблеми с производителността?" Една от опциите е да ги проследите и да свържете актуализациите с промяна в производителността. Съществуват много опции за проследяване на актуализации и в тази публикация ще прегледаме някои от наличните методи, за да можете да изберете и след това да приложите опция, която най-добре пасва на съществуващия ви метод за наблюдение за проблеми с производителността.
Проследяване на SQL
Ако използвате SQL Server 2008 R2 или по-нисък във вашата среда, SQL Trace е един метод, който можете да използвате за улавяне на автоматични актуализации. Скриптът за дефиниране на проследяване, използван по-долу, улавя само събитието Auto Stats, което улавя, когато статистическите данни се актуализират автоматично и когато статистическите данни се създават автоматично. След като тази проследяване се изпълнява известно време във вашата среда, можете да я заредите в таблица и след това да потърсите изхода, за да видите какви актуализации са възникнали. Включеният скрипт по-долу представя пример, използвайки примерната база данни за бейзболна статистика.
Разширени събития
Ако използвате SQL Server 2012 или по-нова версия, препоръчвам да използвате разширени събития за улавяне на автоматични актуализации. Подобно на скрипта за проследяване на SQL, включеният скрипт за дефиниция на сесията улавя само събитията на Auto Stats – отново, както автоматично актуализиране, така и автоматично създаване. След като сесията на XE работи известно време, можете да заредите изхода в таблица през потребителския интерфейс и след това да го запитате, за да видите какви актуализации са възникнали. Включеният скрипт разглежда същия пример като преди, но този път използва разширени събития за събиране на данните.
sys.dm_db_stats_properties
Трета опция, която бихте могли да обмислите, за да наблюдавате актуализациите на статистическите данни, е sys.dm_db_stats_properties DMF, който е наличен само в SQL Server 2008 R2 SP2 и по-нова версия и SQL Server 2012 SP1 и по-нова версия. Колкото и да обичам този DMF, това решение е по-сложно по отношение на това да се уверите, че сте уловили всички данни, а прегледът на изхода изисква повече работа. С DMF всяка автоматична актуализация не се проследява, ние просто актуализираме информацията за актуализацията на статистическите данни, за да видим кога се появят актуализации.
Това е проста задача:създавате таблица, която да съхранява статистическата информация, а след това информацията за моментни снимки от DMF към таблицата редовно. Ключът тук е да разберете колко често да улавяте данните. Всеки час вероятно е излишен, веднъж на ден може да не е достатъчно често. Препоръчвам да започнете със задача на SQL агент, която прави моментни снимки на DMF данните на всеки четири часа. Оставете това да работи няколко дни, след което проверете данните си. Ако статистиката се актуализира най-много веднъж на ден, тогава можете да увеличите интервала на всеки осем или дванадесет часа. Ако статистиката се актуализира лесно на всеки четири часа, намалете интервала до всеки два часа – искате да сте сигурни, че улавяте всяка актуализация. Поради тази причина за някои системи sys.dm_db_stats_properties може да не си струва усилията; XE сесия или Trace може да са по-прости.
Последен примерен скрипт показва пример за това как бихте използвали sys.dm_db_stats_properties за тенденция към актуализации на статистиката. Имайте предвид, че този скрипт улавя статистическа информация само за една таблица. Ако промените скрипта, за да улови всяка таблица в базата данни, ще има много повече данни за анализ.
Следващи стъпки
Изтеглете примерните скриптове и решете кой метод да използвате, за да проследявате актуализациите на статистиката.
След като имате данните, които показват кога се появят автоматични актуализации, трябва да ги свържете с известни проблеми с производителността. Като такъв, ако не проследявате никакви показатели за ефективността, тогава данните за автоматично актуализиране на статистиката няма да помогнат с каквато и да е корелация. Ако приемем, че имате времеви печати за всеки проблем с производителността, можете да го сравните с StartTime и EndTime от Trace, timestamp от XE или last_updated от sys.dm_db_stats_properties DMF, за да определите дали автоматичната актуализация е повлияла на производителността на системата.
Ако не можете да установите никаква връзка между актуализациите и проблемите с производителността, тогава можете да изключите актуализациите като причина за проблема и да се съсредоточите върху друга област. Ако актуализациите са основната причина, тогава имате две опции:деактивирайте опцията Auto Update Statistics или активирайте опцията Auto Update Statistics Asynchronously. И двете имат плюсове и минуси, които вие, като DBA, трябва да вземете предвид.
Деактивиране на статистическите данни за автоматично актуализиране
Ако изберете да деактивирате опцията за автоматично актуализиране на статистиката, двете най-важни неща, които трябва да знаете, са:
- Абсолютно трябва да управлявате статистическите си данни чрез задача за поддръжка или персонализирано задание.
- Заявките няма да се компилират повторно, когато актуализирате статистически данни в SQL Server 2008 R2 и по-долу.
Гледам на втория елемент като на по-голямо предизвикателство – аз съм голям застъпник за управлението на статистиката и очаквам, че все пак това е нещо, което DBA правят. По-големият проблем е, че въпреки че актуализирането на статистическите данни нормално кара заявките да се прекомпилират (за да се възползват от актуализираната статистика), това не възниква, когато сте деактивирали опцията за автоматично актуализиране на статистиката. Писах за това по-рано и препоръчвам да прегледате тази информация, ако не сте запознати с това поведение. Вижте също последваща публикация за опции за справяне с него.
По принцип това не е пътят, който препоръчвам. Има много специфични крайни случаи, когато това може да е подходящо, но бих предпочел да видя DBA да извършва ръчни актуализации (чрез планирани задачи), за да избегне автоматичните актуализации, и да оставя опцията активирана като мярка за безопасност.
Асинхронно активиране на статистическите данни за автоматично актуализиране
Когато активирате опцията Auto Update Statistics Asynchronously, ако статистиката е била невалидна и се изпълнява заявка, която използва тази статистика, статистиката няма да бъде актуализирана, докато заявката не приключи – актуализацията е асинхронна. Предимството тук е, че актуализацията няма да засегне заявката, която е била изпълнена; недостатъкът е, че заявката ще използва съществуващия план, който вече може да не е оптималният план. Дали планът все още е оптимален ще зависи от вашето работно натоварване (напр. отчитане на работното натоварване с продължителни заявки). Като DBA, трябва да претеглите плюсовете и минусите на активиране на тази опция и да определите кое е най-доброто за вашата база данни. Имайте предвид, че ако използвате SQL Server 2008 до 2012, има изтичане на памет, свързано с тази настройка. Microsoft има налични кумулативни актуализации, които предоставят корекция, но ако все още не сте ги приложили, сте изправени пред друго решение:приложите CU, за да можете да активирате опцията, или не прилагайте CU и не активирайте опция.
Резюме
Единственият начин да разберете дали автоматичните актуализации на статистическите данни влияят върху производителността на заявката е или да видите, че актуализацията се появява едновременно с проблем, или да уловите кога се появят актуализации и да съпоставите данните с допълнителна информация, която улавяте за проблеми с производителността. Последната опция ви позволява да бъдете проактивни – дори и да нямате проблеми с производителността, може да е добра идея да знаете колко често се случват автоматични актуализации. Честите актуализации може да означават, че трябва да преразгледате задачата на агент, която ръчно управлява статистиката. Като цяло оставете опцията за автоматично актуализиране на статистиката активирана, но имайте метод за управление на статистиката и използвайте опцията като предпазна мрежа.
