В последната си публикация, „Множество планове за „идентична“ заявка“, говорих за случая, когато получавате два различни плана за това, което смятате, че е една и съща заявка, както и за случая, когато получавате две копия на същото план (и може дори да не го знае). Както разгледахме там, „идентичен“ може да е доста силна дума.
Друг сценарий, който хвърля хората в цикъл, е случаят, когато те възстановяват база данни на различен сървър – да речем, възстановяват производствена база данни на „идентичен“ тестов сървър – и получават различни характеристики на производителност или различни планове за една и съща заявка (не цитати този път – наистина говоря за наистина идентични заявки).
Сървърите наистина ли са „идентични“?
Тези момчета може да изглеждат подобни, но не са съвсем идентични. Ако попаднете на този сценарий, първото нещо, което трябва да се запитате, е дали тези два сървъра наистина са идентични. Някои неща за проверка:
- Версия – Много промени в поведението на оптимизатора и заявките се прокарват чрез сервизни пакети и кумулативни актуализации. Често съм виждал хора да казват:"Е, и двамата са 2008!" – когато всъщност единият беше 2008 г., а другият беше 2008 R2, или бяха с различни сервизни пакети или дори кумулативни нива на актуализация. Тъй като много хора, които четат @@VERSION, бъркат информацията за сервизния пакет на операционната система за информацията за сервизния пакет на SQL Server, бих казал, че следното е по-добре:
SELECTSERVERPROPERTY(N'ProductVersion');Не мога да подчертая достатъчно важността на използването на точно същата версия за извършване на истински тестове от ябълки към ябълки. Ако използвате SQL Server 2012 или по-добър, можете да проверите нашите публикации за изграждане (SQL Server 2012 | SQL Server 2014), за да определите сервизния пакет или кумулативната актуализация, необходими, за да сте сигурни, че версиите съвпадат.
- Издание – Въпреки че се надяваме, че използвате едно и също издание на двата сървъра (или еквивалентно, тъй като освен лицензирането, Developer и Evaluation са същите като Enterprise), несъответствията тук могат да доведат до много различно поведение. Например, различните издания имат различен изчислителен капацитет за различни функции, а след това има по-фини неща като възможността да се използва индексиран изглед без намек за NOEXPAND или да се извършват промени в схемата или онлайн поддръжка на индекса. Можете да сравните изданията, като използвате:
SELECTSERVERPROPERTY(N'Edition'); - Брой на процесора – SQL Server определено използва броя на планировчиците, налични по време на процеса на създаване на план за изпълнение и не може да се отрече, че броят на ядрата може да повлияе на действителната производителност по време на изпълнение (нека пропуснем тактовата честота, тъй като това рядко е важен фактор в заявката производителност). Не просто проверявайте броя на физически инсталираните ядра в основния сървър, но също така проверете регистрационния файл за грешки на SQL Server за броя на процесорите, които SQL Server може действително да използва поради лицензиране. Дори да забравим броя на необработените ядра, в NUMA система изкуствените ограничения тук могат да доведат до много различни профили на производителност. За повече информация вижте скорошната публикация на Брент Озар „Защо лицензирането, базирано на ядрото, има значение за настройката на производителността“. Изданието е свързано и тук, тъй като в SQL Server 2012 и 2014 Standard Edition може да използва само 16 ядра, без значение какви настройки или физически хардуер могат да ви накарат да повярвате. Други настройки, които могат да повлияят на избора на базиран на процесора план и производителността по различен начин, включват Resource Governor, MAXDOP за целия сървър, афинитет на процесора и праг на разходите за паралелизъм.
- Обем памет – Подобно на процесорите, оптимизаторът прави избор на план въз основа на количеството налична памет. И подобно на процесорите, не говоря само за количеството RAM, инсталирана в системата, а за количеството памет, предоставена на SQL Server, и колко наистина използва. Проверете настройките за максимална памет на сървъра, но също и броячите на производителността за общата и целевата памет и дори DBCC MEMORYSTATUS. Други неща, които може да искате да прегледате, включват настройките на Resource Governor и заключващите страници в паметта. Съществува и настройка, която, ако е различна между два сървъра, може да има значителен ефект върху това колко от кеша на плана се използва за същия набор от заявки:оптимизиране за ad hoc работни натоварвания. Кимбърли Трип има страхотна публикация за това:Планиране на кеша и оптимизиране за adhoc работни натоварвания. И накрая, ако сървърът е виртуален, имайте предвид, че средата може да играе роля тук – особено когато настройките на паметта на VM не съвпадат с производството или са динамични.
- Буферен пул/кеш на план – Когато възстановите базата данни на тестовия сървър, има куп неща, които просто не са готови за вас веднага. Буферният пул не съдържа никакви данни, които може да са съществували в изходния сървър – така че ще са необходими допълнителни I/O, за да се заредят данните в паметта при първия път, когато бъдат запитани. И ако буферният пул е ограничен по различен начин от производството поради някои от факторите по-горе, може да не е възможно да се постигнат същите модели на производителност дори след стартиране на заявката многократно – Пол Уайт (@SQL_Kiwi) говори за това в своя отговор на Администратори на бази данни. Също така, кешът на плана няма да съдържа нито един от плановете, които са съществували в производството, така че най-малкото – дори ако в крайна сметка бъде компилиран същият план (което може да не се случи поради различни параметри, отколкото когато планът е компилиран в оригинала сървър) – ще имате допълнителни разходи за компилация. И те могат да се променят, ако имате поставени знаци за проследяване, засягащи плана.
- Дискова подсистема – Въпреки че скоростта и размерът на използваните дискове няма да повлияят пряко на избора на план, те със сигурност могат да повлияят на наблюдаваната производителност, което може да ви накара да се чудите защо една и съща заявка, със същия план, работи толкова по-бързо на един система от другата. I/O обикновено е най-голямото тесно място на SQL Server и е доста рядко тестов сървър наистина да има точно същата основна подсистема като неговия производствен еквивалент. Така че, ако виждате разлики в производителността между двете системи и плановете и другите хардуерни елементи са едни и същи, това може да е следващото най-добро място за проверка. И не забравяйте, че от SQL Server 2014 Resource Governor може да поставя ограничения върху вашата I/O производителност.
- Флагове за проследяване – Проверете списъка с глобални флагове за проследяване, зададени и на двата сървъра; има няколко, които могат да повлияят на оптимизацията, поведението на плана и възприеманата производителност, дори ако всички горепосочени настройки са идентични. Ето 10 често срещани и забележителни (въпреки че това абсолютно не е одобрение за включване на някое от тях без задълбочено регресионно тестване):
Flag Обяснение 2301 Принуждава оптимизатора да прекарва повече време в опити за намиране на оптимален план. 2312 Принуждава новия оценител на мощността на SQL Server 2014. 2335 Предизвиква по-консервативно предоставяне на памет. 2453 Принуждава OPTION (RECOMPILE) за заявки, препращащи променливи в таблицата. 2861 Позволява на SQL Server да кешира тривиални / нулеви планове. 4136 Ефективно добавя ОПТИМИЗАЦИЯ ЗА НЕИЗВЕСТНО към всички заявки (за осуетяване на подслушването на параметри). 4199 Чадър, съдържащ цял набор от корекции за оптимизатор. 8744 Деактивира предварителното извличане за вложени цикли. 9481 Изключва новия оценител на мощността на SQL Server 2014.
Този списък с флагове за проследяване в никакъв случай не е изчерпателен; има много други, включително недокументирани, които ме помолиха да не споменавам. Ако използвате други, които не са изброени по-горе (и не можете да обясните защо), може да намерите улики в KB #920093, KB #2964518, Trace Flags (MSDN) или Trace Flags в SQL Server (TechNet). Също така ще намерите ценна информация в различни публикации на Пол Уайт, тук или на sql.kiwi. - Паралелност – Вероятно тестовата система се използва за неща, различни от това, което тествате в момента. И освен ако не извършвате някакво повторение, то вероятно също има много различен профил на натоварване. Тези разлики в натовареността очевидно могат да имат пряко въздействие върху наличието на ресурси за обслужване на заявките, които тествате, и от своя страна на възприеманата производителност на тези заявки. Не забравяйте да проверите за други услуги, които може да не съществуват в производството или съществуват, но се използват по различни начини (като Analysis Services, Reporting Services, Windows услуги и дори вашите собствени приложения). Обратно, може да има услуги като тази в производството, които влияят на производителността там, или допълнителни режийни разходи за самия екземпляр, който не се имитира в теста:освен действителното производствено натоварване, помислете за неща като проследяване, разширени събития, мониторинг с голямо въздействие, проследяване на промените, улавяне на промяна на данни, одит, брокер на услуги, поддръжка на индекси, резервни задачи, DBCC проверки, огледално копиране, репликация, групи за наличност и списъкът продължава и продължава...
Базите данни все още ли са „идентични“?
Ако приемем, че всички променливи на хардуера и работното натоварване съвпадат достатъчно добре, все още може да бъде предизвикателство да се гарантира, че базите данни остават същите. Ако извършвате архивиране/възстановяване на тестовата система, новата база данни започва като идентична с източника (с изключение на физическото местоположение и сигурността). Но веднага щом започнете да го докосвате по какъвто и да е начин, той много бързо се отклонява от производственото копие, тъй като можете да направите някое или всички от следните неща:
- Променете данните, схемата или и двете.
- Неволно стартиране на автоматично актуализиране на статистиката.
- Ръчно добавяне, дефрагментиране или възстановяване на индекси или създаване или актуализиране на статистически данни.
- Променете настройките на базата данни като ниво на съвместимост, ниво на изолация, принудителна параметризация, селективни XML индекси или някоя от опциите, наречени „Автоматично“-<всичко>. (По дяволите, дори местоположенията на данни и регистрационни файлове и настройките за растеж могат да повлияят на производителността на заявката и това включва tempdb.)
- Изпразнете кеша на плана, буферния пул или и двете, директно или като страничен ефект от други събития (като ПРЕКОНФИГУРИРАНЕ или рестартиране на услугата).
Освен това, след като започнете да генерирате нови планове за заявки, дори преди да се осъществи някоя от горните промени, трябва да запомните, че те може да се основават на данни, които са различни от данните, използвани за генериране на планове за същите заявки в производството. Като пример, кардиналността, когато планът е съставен в производството, може да се отклони значително между тази точка и времето на архивирането, което означава, че новият план ще бъде генериран въз основа на различни статистически данни и информация за хистограмата.
Тези неща се разминават още повече, ако това всъщност не е скорошно възстановяване – а по-скоро две схеми и набори от данни, които поддържате синхронизирани по други начини (като ръчно внедряване на схеми и/или промени в данните, или дори репликация). Поради ограниченията на дисковото пространство може също да сте взели само подмножество от производствени данни или дори клонинг само със статистика – тези разлики в данните почти сигурно ще доведат до различни характеристики на производителност за всички, освен най-простите заявки, дори ако го направите късмет и имайте същите планове за някои.
Заявките наистина ли са „идентични“?
Дори ако всичко по-горе се изпълни, все още има сценарии, при които получавате различен план поради настройките на сесията (може да използвате различно копие на SSMS, с различни настройки или изцяло различен клиентски инструмент) или различни схеми по подразбиране ( може да се свързвате с тестовия сървър като различно Windows или SQL удостоверяване, например). Говорих много за тези неща в предишната си публикация.
Заключение
Въпреки че има начини за смекчаване на някои разлики (вижте DBCC OPTIMIZER_WHATIF за заблуждаване на вашия тестов сървър да вярва на феноменални неща за основния хардуер), истината е, че ще бъде много предизвикателство да накарате два сървъра да работят надеждно и постоянно идентични, и че има потенциално десетки причини, поради които може да получите различни планове или различна производителност на два подобни (или дори идентични) сървъра.
Имате ли някакви особени трикове? Имате ли някакви мъчителни болкови точки с идеите по-горе (или други, които пропуснах да спомена)? Моля, споделете в коментарите по-долу!
