Пример за оценка на нивата на съвместимост и кардиналността

Въведение

Между 1998 г. и началото на 2014 г. SQL Server използва един оценител на мощността (CE), но въвежда ново ниво на съвместимост на базата данни с всяка нова основна версия на SQL Server (с изключение на SQL Server 2008 R2). Вградените нива на съвместимост за SQL Server са показани по основна версия на SQL Server в Таблица 1:

Таблица 1:Версии на SQL Server и естествени нива на съвместимост

Между SQL Server 7.0 и SQL Server 2012 нямаше връзка между нивото на съвместимост на база данни и оценителя на мощността, който ще използват заявките в тази база данни. Това е така, защото имаше само един оценител на мощността, който получи голяма актуализация през 1998 г. Нивото на съвместимост на база данни се използва само за обратна функционална съвместимост и за активиране/деактивиране на някои нови функции във всяка нова версия на SQL Server (вижте това Отговорът на Stack Exchange за примери за промяна на поведението между 80 и 90, вероятно най-разрушителната промяна). За разлика от файловата версия на база данни на SQL Server, можете да промените нивото на съвместимост на база данни по всяко време на всяко поддържано ниво на съвместимост с проста команда ALTER DATABASE.

По подразбиране, ако сте създали нов база данни в SQL Server 2012, нивото на съвместимост ще бъде настроено на 110, но можете да го промените на по-ранно ниво, ако желаете. Ако стевъзстановили архивиране на база данни от екземпляр на SQL Server 2008 в екземпляр на SQL Server 2012, той ще надстрои файловата версия на базата данни, но ще остави нивото на съвместимост, където е било на екземпляр на SQL Server 2008 (освен ако не е 80, което би надстройте до 90, минималната версия, поддържана от SQL Server 2012). Освен че знаеха фундаменталната разлика между файловата версия на базата данни и нивото на съвместимост на базата данни, повечето администратори на база данни и разработчици не трябваше да се тревожат много за нивата на съвместимост на базата данни преди пускането на SQL Server 2014. В много случаи нивата на съвместимост на повечето бази данни никога не са се променяли след миграция към нова версия на SQL Server. Това обикновено не причинява проблеми, освен ако всъщност не се нуждаете от нова функция или поведение, които са се променили в последното ниво на съвместимост на базата данни.

Промени в SQL Server 2014

Това старо състояние на нещата се промени радикално с пускането на SQL Server 2014. SQL Server 2014 въведе „нов“ оценител на мощността, който беше активиран по подразбиране когато база данни е на ниво 120 на съвместимост. В класическата бяла книга „Оптимизиране на вашите планове за заявки с SQL Server 2014 Cardinality Estimator“ Джо Сак обяснява фона и поведението на тази промяна през април 2014 г. В много случаи повечето от вашите заявки се изпълняваха по-бързо, когато използвате новата мощност оценител, но беше доста често да се сблъскате с някои заявки, които имат големи регресии на производителността с новия оценител на мощността. Ако това се случи, SQL Server 2014 нямаше толкова много опции за облекчаване на проблемите с производителността, причинени от новия CE. Бялата книга на Джо обхваща тези опции в много подробности, но по същество сте били ограничени до флагове за проследяване на ниво екземпляр или подсказки за заявка на ниво заявка, за да контролирате кой оценител на мощността е бил използван от оптимизатора на заявки, освен ако не искате да се върнете към ниво на съвместимост 110 или по-ниско .

Промени в SQL Server 2016

SQL Server 2016 въведе опции за конфигурация с обхват на база данни, които ви дават възможност да контролирате някои поведения, които преди са били конфигурирани на ниво потребителски модел, като използвате команда ALTER DATABASE SCOPED CONFIGURATION. В SQL Server 2016 тези опции включват MAXDOP, LEGACY_CARDINALITY ESTIMATION, PARAMETER_SNIFFING и QUERY_OPTIMIZER_HOTFIXES. Имаше и опция CLEAR PROCEDURE_CACHE, която ви позволява да изчистите целия кеш на плана за една база данни.

Най-подходящи в този контекст са опциите за конфигурация с обхват на база данни LEGACY_CARDINALITY ESTIMATION и QUERY_OPTIMIZER_HOTFIXES. LEGACY_CARDINALITY ESTIMATION разрешава наследеното CE независимо от настройката на нивото на съвместимост на базата данни. Той е еквивалентен на флаг за проследяване 9481, но засяга само въпросната база данни, а не целия екземпляр. Позволява ви да зададете нивото на съвместимост на базата данни на 130, за да получите редица функционални и производителни ползи, но все пак да използвате наследената CE база данни за цялата база данни (освен ако не е отменено от намек за заявка на ниво заявка).

Опцията QUERY_OPTIMIZER_HOTFIXES е еквивалентна на флаг за проследяване 4199 на ниво база данни. SQL Server 2016 ще активира всички актуални корекции на оптимизатора на заявки преди SQL Server 2016 RTM, когато използвате ниво на съвместимост на базата данни 130 (без да активирате флаг за проследяване 4199). Ако активирате TF 4199 или активирате QUERY_OPTIMIZER_HOTFIXES, ще получите и всички актуални корекции на оптимизатора на заявки, които бяха пуснати след SQL Server 2016 RTM.

SQL Server 2016 SP1 също въведе съветите за заявка USE HINT, които са по-лесни за използване, разбиране и запомняне от по-старите съвети за заявка QUERYTRACEON. Това ви дава още по-фин контрол върху поведението на оптимизатора, което е свързано с нивото на съвместимост на базата данни и версията на кардиналния оценител, който се използва. Можете да заявите sys.dm_exec_valid_use_hints, за да получите списък с валидни имена на USE HINT за точната компилация на SQL Server, който изпълнявате.

Промени в SQL Server 2017

Новата функция за адаптивна обработка на заявки беше добавена в SQL Server 2017 и е активирана по подразбиране, когато използвате ниво на съвместимост на базата данни 140.

Microsoft се опитва да се отдалечи от старата терминология на „Ново CE“ и „Old CE“, тъй като всъщност има промени и поправки за оптимизация на заявки във всяка нова основна версия на SQL Server. Поради това вече няма нито едно „Ново СЕ“. Вместо това Microsoft иска да се позовава на CE70 (CE по подразбиране за SQL Server 7.0 до SQL Server 2012), CE120 за SQL Server 2014, CE130 за SQL Server 2016, CE140 за SQL Server 2017 и CE150 за SQL Server SQL Server 2019. 2017 CU10, можете да използвате функционалността USE HINT, за да контролирате това със съвети за заявка. Например:

/*...query...*/ OPTION (USE HINT('QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_130'));

… би било валиден намек за заявка за принудително използване на CE130 оценка на мощността за конкретна заявка.

Промени в SQL Server 2019

SQL Server 2019 добавя още повече подобрения в производителността и промени в поведението, които са активирани по подразбиране, когато база данни използва режим на съвместимост 150. Отличен пример е скаларното вграждане на UDF. Друг пример е функцията за интелигентна обработка на заявки, която е надмножество на адаптивната обработка на заявки в SQL Server 2017.

Има пет нови опции USE HINT, включително начини за деактивиране на пакетен режим или деактивиране на обратната връзка за предоставяне на адаптивна памет, както е показано в Таблица 2:

Таблица 2 :Нови опции за ИЗПОЛЗВАНЕ НА СЪВЕТ

Освен това има шестнадесет нови опции за конфигурация с обхват на база данни (от CTP 2.2), които ви дават контрол на ниво база данни за повече елементи, които също са засегнати от флагове за проследяване или ниво на съвместимост на базата данни. Той ви дава по-фин контрол върху промените от по-високо ниво, които са активирани по подразбиране с ниво на съвместимост на базата данни 150. Те са изброени в Таблица 3:

Таблица 3:Нови опции за конфигурация в обхвата на базата данни

Заключение

Мигрирането към съвременна версия на SQL Server (което означава SQL Server 2016 или по-нова) е значително по-сложно, отколкото при наследените версии на SQL Server. Поради промените, свързани с различните нива на съвместимост на базата данни и различните версии на оценителя на мощността, всъщност е много важно да се обмислят, планират и действително тестват кое ниво на съвместимост на базата данни искате да използвате в новата версия на SQL Server, която мигрират съществуващите ви бази данни към.

Препоръчителният процес на надстройка от Microsoft е да надстроите до най-новата версия на SQL Server, но да запазите нивото на съвместимост на изходната база данни. След това активирайте хранилището на заявки във всяка база данни и събирайте базови данни за работното натоварване. След това задавате нивото на съвместимост на базата данни на най-новата версия и след това използвате Query Store, за да коригирате регресиите в производителността, като форсирате последния известен добър план.

Наистина искате да избегнете случайна „сляпа“ миграция, при която блажено не сте наясно как работи това и как работното ви натоварване ще реагира на тези промени. Промяната на нивото на съвместимост на базата данни на подходяща версия и използването на подходящи опции за конфигурация в обхвата на базата данни, заедно с подходящи съвети за заявка, където е абсолютно необходимо, е изключително важно за съвременните версии на SQL Server.