Колко време отделяте за отстраняване на проблеми с производителността като администратор на база данни или разработчик? Проследили ли сте го някога? Като среден общ процент от деня ви, може да не изглежда много време, но когато проблемът е сериозен, можете да прекарате часове, за да го проследявате и да работите чрез анализ на основната причина. Понякога проблемът изчезва и вие не знаете истинския произход. И още по-лошо? Когато трябва да се борите с тези проблеми посред нощ или през уикенда. Не само се опитвате да разрешите проблем, но губите личното си свободно време. Как да облекчим това? Как да отделим времето и усилията си от уравнението и да коригираме производителността в същото време?
Функцията за автоматична настройка в SQL Server 2017 Enterprise Edition и Azure SQL база данни е първата стъпка за намаляване на времето, което специалистите по данни прекарват в отстраняване на неизправности и решаване на проблеми с производителността. Функцията включва автоматично коригиране на плана и автоматично управление на индекси (достъпно само в Azure SQL база данни), които са активирани независимо. В тази публикация искам да се съсредоточа върху функцията за автоматична корекция на плана. С автоматичната корекция на плана, ако SQL Server установи, че дадена заявка е регресирала значително, тя ще принуди последния известен добър план за заявката да стабилизира производителността. По същество, вместо вас, DBA или разработчика, да ви се обаждат през уикенда относно производителността на системата, SQL Server ще се справи вместо вас. Звучи твърде лесно, нали? Нека да разгледаме.
Под завивките
Първо, важно е да разберете, че автоматичната корекция на плана използва хранилище на заявки, така че трябва да бъде активирано за базата данни. Второ, автоматичната корекция на плана е просто автоматично налагане на план. Докато Query Store се предлага на пазара като записващо устройство за полети за вашата база данни, което проследява текста на заявката, плановете, статистическите данни за времето на изпълнение и статистическите данни за чакане, то също така ви позволява да наложите план за заявка, за да позволите последователна производителност. Автоматичната корекция на плана е налагане на план без ваша намеса.
Активиране на автоматична корекция на план
Както споменахме, Query Store трябва първо да бъде активиран за потребителската база данни. Това може да се направи в SSMS, с T-SQL и с REST API за Azure SQL DB. Имайте предвид, че хранилището на заявки е активирано по подразбиране за бази данни в Azure и е от четвъртото тримесечие на 2016 г.
Активиране на хранилището на заявки чрез SSMS
USE [master]; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE = ON; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE (OPERATION_MODE = READ_WRITE); GO
Активиране на хранилището на заявки чрез T-SQL
Горният код е T-SQL по подразбиране от SSMS, ако го скриптирате. В Azure SQL база данни не изпълнявате оператора USE. Ако искате да промените някоя от опциите по подразбиране, моля, прочетете публикацията ми за настройките на магазина за заявки относно това какви са тези опции и съображенията за алтернативни стойности.
След като хранилището на заявки е активирано, можете да използвате Azure Portal, T-SQL или EST API, за да активирате автоматичната корекция на плана в Azure SQL база данни ((и C# и PowerShell са в процес на работа). Може да се активира само с T-SQL в SQL Server 2017.
Активиране на автоматична корекция на плана в Azure Portal
ALTER DATABASE [WideWorldImporters] SET AUTOMATIC_TUNING ( FORCE_LAST_GOOD_PLAN = ON ); GO
Активиране на автоматична корекция на плана в T-SQL
Имайте предвид, че автоматичната корекция на плана ще бъде активирана по подразбиране за нови бази данни в Azure в близко бъдеще. От януари 2018 г. автоматичното настройване се активира за Azure SQL бази данни, които все още не са го активирали, като се изпращат известия до администраторите, така че опцията може да бъде деактивирана, ако желаете.
Как работи
С активирана автоматична корекция на плана, SQL Server следи производителността на заявката, използвайки данни от хранилището на заявки. Той търси значителна промяна* в производителността на процесора** с 48-часов прозорец***. Обърнете внимание на звездичките в това изречение... те са нарочно:
- *Прагът за това, което представлява значителна промяна, не е документиран, тъй като Microsoft си запазва правото да го промени.
- **Показателят, използван за определяне на промяната в производителността (CPU), не е документиран, защото Microsoft си запазва правото да го променя. Това означава, че Microsoft може да обмисли допълнителни измерения, за да разгледа производителността, ако това би било по-добре/по-добре от CPU само.
- ***Периодът от време, през който се сравняват данните за ефективността на заявката, не е документиран по същата причина, Microsoft си запазва правото да го промени.
- Забележка:въпреки че гореспоменатите елементи не са документирани, аз потвърдих със съответните лица в Microsoft, че тази информация може да бъде споделена с нарушаване на всеки NDA. Изключително важно е да се разбере, че стойностите не са фиксирани и могат да се променят, с очакването, че ще се променят, за да подобрят надеждността на функцията.
Липсата на документация и възможността за промени в прага може да са разочароващи за някои хора, но ето какво е наистина важно да запомните:
Microsoft улавя терабайти оперативни телеметрични данни от SQL Azure бази данни ежедневно и тези данни са от решаващо значение за автоматичните функции, които се разработват. Тези данни включват неща като query_id, query_plan_id и query_hash, а Microsoft НЕ улавя query_text или query_plan (те не разглеждат вашите действителни данни). Microsoft не просто архивира тази оперативна телеметрия или я използва за отстраняване на неизправности, те извличат тези данни и ги използват за разработване на алгоритми и модели, които позволяват на SQL Server да взема независими, интелигентни решения.
SQL Server може да се възползва от множеството данни в хранилището на заявки, които детайлизират производителността на заявките, а автоматичната корекция на плана започва със сравняване на текущата производителност за заявка с минала производителност, за да се определи дали има регресия в производителността. Намаля ли е производителността или се е влошила и ако да, значи ли е?
Ако е имало регресия в производителността на заявката, тогава SQL Server ще наложи последния известен добър план за тази заявка, който разбира се е изтеглен от Query Store. Но това не спира дотук. След това SQL Server продължава да наблюдава производителността – все още използвайки хранилището на заявки – за да потвърди, че принудителният план все още е добър план за тази заявка, което означава, че заявката с принудителния план се представя по-добре от регресираната версия. Ако тази заявка не работи по-добре, тя ще отмени плана. Планът може също да бъде отменен, ако има прекомпилиране или ако принудителното налагане се провали.
Този цикъл продължава; ако заявка има принудителен план и след това този план не е принуден поради една от гореспоменатите причини, същият план може да бъде принуден отново по-късно или може да има друг план, принуден за тази заявка по-късно. Това е непрекъснат процес, който се случва, стига да имате активирана опцията за автоматично коригиране на плана за базата данни. Сега, това, което е интересно е, че можете да разгледате същата информация, която тази функция улавя и да я използвате, за да принудите плановете ръчно. Тоест в SQL Server 2017 Enterprise Edition и в Azure SQL база данни тези данни се събират в sys.dm_db_tuning_recommendations DMV дори когато функцията за автоматично коригиране на плана не е активирана, така че можете да прегледате тези данни и да следвате препоръките му, за да наложите плановете за собствени конкретни запитвания. Имайте предвид, че ако наложите план, използвайки препоръки от sys.dm_db_tuning_recommendations, той никога няма да бъде автоматично отменен. Освен това, ако имате активирана автоматична корекция на плана и ръчно наложите план, той никога няма да бъде автоматично отменен. Само планове, които са принудени с функцията за автоматично коригиране на план, ще бъдат отменени автоматично.
Наистина ли ще позволя на SQL Server да има контрол?
Ако сте скептични и се чудите дали наистина можете да се доверите на SQL Server за вземане на решение, налагащо план, ето какво бих ви насърчил да запомните:
- Тази функция е разработена със зашеметяващо количество данни, уловени от почти два милиона Azure SQL бази данни. Това е нова функция в SQL Server 2017, но я направи глобална наличност през 2016 г. в Azure, така че тази функция наистина е налична от повече от година и беше усъвършенствана.
- Инженерите са направили промени в алгоритъма с течение на времето, тъй като са уловили повече данни. Може да не открие всяка регресия, която се случва – защото регресията може да не е достатъчно тежка, но бих се обзаложил, че много от вас биха предпочели да използват тази функция по-рядко, отколкото твърде често.
- На всичкото отгоре, ако планът е принуден, но в крайна сметка причинява проблем, способността на SQL Server да се възстанови от това и да отмени плана е изключително надеждна и се случва много бързо.
Резюме
Може да не ви харесва идеята SQL Server да се занимава с проблеми с производителността вместо вас. Но дали това е дискомфорт, защото смятате, че ще вземе лошо решение? Или се притеснявате дали автоматизацията ще поеме работата ви? Доста директен въпрос, знам. Ако е първото, тогава моята препоръка е да погледнете данните, заснети в sys.dm_db_tuning_recommendations (без да активирате автоматична корекция на плана) и да видите какво би искал да направи SQL Server. Съвпада ли с това, което бихте направили? Открива ли регресии, които може да пропуснете? Ако не искате да активирате функцията, защото се страхувате, че изведнъж няма да имате достатъчно работа, препоръчвам ви да прочетете скорошната публикация на Conor Cunningham, Как скоростта на облака помага на SQL Server DBA. Microsoft не се опитва да ви извади от работа. Те просто се опитват да се справят с ниско висящите плодове, за да можете да се съсредоточите върху по-важни задачи.
