Database
 sql >> база данни >  >> RDS >> Database

Уебинар за Plan Explorer 3.0 – Примери и въпроси и отговори

Миналия петък направих уебинар за Plan Explorer 3.0, новите функции и защо решихме да премахнем PRO изданието и да предоставим всички функции безплатно . Ако сте го пропуснали, можете да гледате уебинара тук:

    Планирайте уебинар за Explorer 3.0

Бяха изпратени много страхотни въпроси и ще се опитам да отговоря на тях тук. Зададохме и няколко от нашите собствени въпроса в различни моменти по време на презентацията и потребителите поискаха подробности за тях, така че ще започна с въпросите на анкетата. Имахме пик от 502 присъстващи и ще посоча в диаграмите по-долу колко души са отговорили на всеки въпрос. Тъй като първият въпрос беше зададен преди технически да започне уебинарът, по-малък брой хора отговориха на този.

Въпроси от публиката

В:Налични ли са примерните кодове?

А: Да, трите сесийни файла, които използвах за моите демонстрации, са налични тук:

    Демонстрации за уеб семинари на Plan Explorer 3.0

Можете да ги отворите в най-новата версия на Plan Explorer, но ако искате да стартирате някоя от заявките отново локално, ще ви трябва AdventureWorks2014 (с увеличаващия се скрипт от Jonathan Kehayias) и/или новата примерна база данни Wide World Importers.

В:Значи всичко показано днес е в новия, унифициран, безплатен Plan Explorer? Ако е така, какъв е новият модел на приходите на вашата компания?

А: Винаги се изненадвам, когато срещам хора, които смятат, че всичко, което предлагаме, е Plan Explorer (виждам ги лично и имаше няколко подобни коментара и в публикацията на Грег в блога). Нашият истински хляб и масло е в нашата платформа за наблюдение и се надяваме, че вашият положителен опит с Plan Explorer ще ви накара да изпробвате и другите ни решения.

В:Все още използваме SQL Server 2008. Има ли предимства от използването на PE срещу SSMS?

А: Да, макар че ще пропуснете някои от функционалностите (като Профил на заявка на живо), има много повече информация, налична за вас в сравнение със SSMS, и ние полагаме усилия да направим конкретни проблеми много по-откриваеми.

В:Ще работи ли Live Query Profile за SQL Server 2014?

А: Да, стига да се прилага Service Pack 1, тъй като функцията разчита на DMV, добавен в SQL Server 2014 SP1.

В:Какви са ограниченията по отношение на SQL Server 2012? Мога ли изобщо да използвам този инструмент?

А: Абсолютно. Ограничението, което споменах по време на уебинара относно SQL Server 2012 и по-ниски, е, че те не могат да заснемат данни от Live Query Profile.

В:Данните събират ли се само за SQL Server 2014 и по-нови версии? Ами ако SQL Server 2014 е инсталиран, но съвместимостта е настроена на 2012?

А: Да, Live Query Profile (и диаграмите с ресурси) работи в SQL Server 2014 (с поне SP1), SQL Server 2016 и Azure SQL база данни. Не се влияе от нивото на съвместимост.

В:Коя версия на SQL Server е необходима, за да се върне информацията за статистиката за чакане?

А: Събирането на статистически данни за чакане разчита на сесия с разширени събития, така че трябва да работите срещу SQL Server 2008 или по-нова версия и да изпълнявате в контекста на потребител или влизане с достатъчно разрешения, за да създадете и пуснете сесия с разширени събития (CONTROL SERVER в SQL Server 2008 и 2008 R2 и ALTER ANY EVENT SESSION в SQL Server 2012 и по-нова версия).

В:Как да покажа анализ на индекса или диаграмите на профила на заявка на живо?

А: Имаше много вариации на тези два въпроса и от звуците на това хората активно играеха с новата версия по време на уебинара и не виждаха нито данните от индексния анализ, нито данните от профила на Live Query. Ако имате съществуващ план, заловен от SSMS или по-ранна версия на Plan Explorer, няма да има информация за показване.

За да събира Индекс анализ данни, трябва да генерирате прогнозен или действителен план от Plan Explorer. За да видите мрежа с колони и индекси, трябва да изберете Избрана операция:в падащото меню в горната част на раздела Анализ на индексите.

За да съберете Профил на заявка на живо данни, трябва да генерирате действителен план от Plan Explorer и да работи срещу 2014 SP1 или по-добър. Трябва също така да се уверите, че сте избрали опцията „С Live Query Profile“ (вижте изображението вдясно) и да изчакате изпълнението на заявката да приключи, преди диаграмите да се изобразят. В бъдеща версия диаграмите ще се изобразяват в реално време, но в тази версия ние правим това, след като всички данни бъдат събрани.

В:Функционира ли Live Query Profile срещу клонирани бази данни в SQL Server 2014 SP2?

А: Да, това ще работи, но няма да предостави много информация, тъй като клонираната база данни е празна – ще видите правилните прогнози в плана, но действителните всички ще бъдат 0 и така показателите за време на изпълнение няма да представляват реалистични или смислени тесни места. Освен ако не попълвате клонинга с алтернативни данни, както Ерин Стелато популяризира в по-ранна публикация. Също така имайте предвид, че ако искате плановете за заявки да отразяват реалните размери на производствените данни, ще искате да се уверите, че всички форми на автоматични статистически данни са изключени, в противен случай те ще бъдат актуализирани, докато изпълнявате заявки, и тогава всички оценки ще бъдат 0.

В:Новата версия на Plan Explorer работи ли със SQL Server 2016?

А: да. Поддържаме всички нови оператори на планове на SQL Server 2016 и други промени в плана за показване (вижте публикацията ми, „Поддръжка на Plan Explorer за SQL Server 2016“), а добавката работи и с най-новата версия на SSMS (вижте публикацията ми, „Обявяване на поддръжка на добавки за Plan Explorer за SSMS 2016“).

В:Така че дори действителният план за изпълнение в SSMS е обозначен с приблизителен разходи?

А: Да, така е. Когато улавяте данни от Live Query Profile, ние можем да променим процентите на разходите за всички оператори, тъй като знаем със значителна степен на точност колко действителна работа е извършила всяка операция (заявката обаче трябва да работи по-дълго от праг). Това може да бъде особено полезно, ако отстранявате проблем с I/O, тъй като оценките никога не отчитат тесните места за вход/изход. Следните графични цикли преминават през първоначалните прогнози (винаги можем да ви покажем какво би ви казал SSMS), действителните след преоценяване и действителните след преоценяване и промяна на разходите на „по I/O“ и ширините на линиите до "по размер на данните":

В:Преди отварях своя план, създаден от SSMS в Plan Explorer, но от това, което Аарон току-що показа, разбрах ли правилно, че трябва да изпълнявам заявките си (по време на настройка) от Plan Explorer?

А: Разгледах този въпрос в уебинара, но за да е ясно, мисля, че има две стъпки в развитието на заявката:(1) осигуряване на правилни резултати и (2) оптимизиране на производителността. Силно вярвам, че в момента трябва да използвате SSMS за (1) и Plan Explorer за (2). Дълго рекламирах, че след като хората са сигурни, че имат правилни резултати, те трябва да се настройват, като генерират действителни планове за изпълнение от Plan Explorer, защото ние събираме много повече информация по време на изпълнение за вас. Тази информация по време на изпълнение е особено полезна, ако споделите плановете си на нашия сайт за въпроси и отговори, тъй като прави всички показатели и потенциални пречки много по-очевидни.

В:Какви са процентите под оператора... например тези 2885% под функцията?

А: Този процент не е разход, а по-скоро % от редовете, които действително са били обработени в сравнение с прогнозата. В този случай SQL Server изчисли, че функцията ще върне 10 000 реда, но по време на изпълнение е върнала близо 300 000! Можете да видите подсказка, ако задържите курсора на мишката само върху това % число и можете да видите разликите в приблизителната оценка на броя на редовете в подсказката за оператора или в други мрежи като Топ операции (функцията връща различен брой редове сега от този по време на демонстрацията):

В:Можете ли да минимизирате или скриете частта за повторение, за да имате повече недвижими имоти за самия план?

А: Да, всички наши панели са регулируеми; много от тях имат щифт, който превключва между статично и автоматично скриване, повечето панели могат да се плъзгат наоколо (точно както във Visual Studio, SSMS и т.н.), а панелът за повторно възпроизвеждане има малка стрелка в горния център, която ви позволява за бързо показване/скриване:

В:Можете ли да видите кодовия блок направо от плана?

А: Не съм сигурен дали тълкувам правилно въпроса, но всички наши панели са контекстно-чувствителни и изявлението за плана, който в момента се разглежда, се показва както в решетката на изявленията, така и в панела с текстови данни:

Ако текстът на изявлението не е напълно видим поради дължината, винаги можете да щракнете с десния бутон върху тази клетка и да изберете Копиране на изявлението в командата за копиране на текст и след това да преминете към този раздел. Или, ако не искате да презапишете текущото съдържание на раздела Команден текст, изберете Копиране> Клетка и поставете в нова сесия, SSMS или друг редактор.

В:Как мога да спра „Вземете действителен план“, ако по погрешка започнах заявка за 1 час?

А: Ако в момента се изпълнява заявка, има бутон Стоп в лентата на състоянието, долу вляво:

В:Не би ли било по-добре да използвате DROP_EXISTING =ON, вместо първо да пускате индекс и да създавате нов?

А: Определено имаме планове да направим индексните скриптове по-стабилни в бъдеще, включително опции като DROP_EXISTING и ONLINE.

В:Това свързва ли се със SentryOne?

А: Цялата функционалност в Plan Explorer е достъпна и в SentryOne Client. Технически не е необходимо да инсталирате Plan Explorer, ако имате клиент, освен че актуализациите се изпращат по различен график, така че в много случаи може да има смисъл и двете да са инсталирани.

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

В:Каква е производителността на тези нови функции?

А: Повечето от информацията, която събираме, не е по-скъпа, отколкото ако изпълнявате същите заявки и събирате едни и същи данни по време на изпълнение от Management Studio (например с включени SHOWPLAN, STATISTICS TIME и STATISTICS IO). Голяма част от това обаче се компенсира от нашето поведение по подразбиране на отхвърляне на резултати, така че не натоварваме сървъра с усилията за предаване на резултати към нашето приложение.

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

За наистина продължителни или ресурсоемки заявки, най-голямата ми грижа би била нашата колекция Live Query Profile. Имаме две предпочитания, които могат да помогнат за това:дали да включим Live Query Profile с цялото действително генериране на план по подразбиране и какъв интервал да събираме данни от DMV. Въпреки че все още смятам, че режийните разходи за тази колекция никога не трябва да се доближават до режийните разходи на самата заявка, можете да настроите тези настройки, за да направите колекцията по-малко агресивна.

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

В:Има ли нещо, което да помогне за изграждането на филтрирани индекси?

А: Понастоящем нямаме функционалност, която да препоръчва филтрирани индекси, но определено е на нашия радар.

В:Имате ли планове за добавяне на функция за сравнение на план на заявки към Plan Explorer?

А: Да, това със сигурност е в нашата пътна карта много преди тази функционалност да бъде въведена в SSMS. :-) Ще отделим време и ще изградим набор от функции, който се надяваме да очаквате от нас.

В:Можете ли да използвате с пакети SSIS, за да разберете производителността на пакет?

А: Предполагам, че бихте могли, ако извикате пакета или заданието чрез T-SQL срещу сървър (Plan Explorer няма възможност да стартира неща като SSIS пакети директно). Но приложението ще показва само аспектите на производителността, които са видими чрез SQL Server – ако има неефективност в пакета SSIS, които не са свързани с изпълнението срещу SQL Server (да речем, безкраен цикъл в задача на скрипт), ние сме няма да можем да ги вземем, защото нямаме видимост и не извършваме анализ на код.

В:Можете ли бързо да покажете как да използвате функцията за анализ на безизходица?

А: Пропуснах този въпрос по време на уебинара, но говоря за тази функционалност в моя демо комплект, Джонатан Кехайяс е написал за нея в блог тук, Стив Райт има видео за това в YouTube, а официалната документация може да бъде прегледана в Ръководството за потребителя на PE.

В:Може ли това да се използва като Profiler? Мога ли да анализирам цялото натоварване?

А: Plan Explorer е предназначен да помогне за анализиране на отделни заявки и планове за тяхното изпълнение. Имаме пълнофункционална платформа за наблюдение за по-големи усилия и има няколко инструмента за анализ на работното натоварване на трети страни.

В:Много съм нов в настройката на заявките – бихте ли ми предложили инструменти и статии за по-задълбочено разбиране?

А: Има много ресурси за подобряване на настройката на заявки:

  • Всяка T-SQL книга от Ицик Бен-Ган, Грант Фричи или Бенджамин Неварез;
  • Всяка публикация в блог от Пол Уайт или Роб Фарли;
  • Въпроси и отговори тук на answers.sqlperformance.com или повече на dba.stackexchange.com;
  • Заявка за настройване на видеоклипове в YouTube;
  • Демо комплектът (с нова версия скоро!); и,
  • Практика . Сериозно. Можете да прочетете всички книги и статии, които искате, но без практическо, практическо отстраняване на неизправности и подобряване на проблемни заявки с реални проблеми с производителността, ще бъде трудно да станете експерт. ИМХО.

Резюме

Благодаря за участието в уебинара и много благодаря за всички страхотни въпроси. Съжалявам, че не успях да се обърна към всички, но се надявам, че това е било полезно все пак. Ако имате въпрос, който не съм отговорил по-горе, моля, не се колебайте да ме попитате директно на [email protected].


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Две особености на разделяне

  2. Трансформирайте ODBC данни в CloverDX

  3. Най-близкото съвпадение, част 2

  4. Запитвания към базата данни:Как да намеря игла в купа сено?

  5. WordPress – Зад кулисите, част 2