В хода на наблюдение на производителността или отстраняване на проблем, като например бавност на системата, може да се наложи да се намерят или уловят заявки, които имат голяма продължителност, висок процесор или генерират значителен вход/изход по време на изпълнение. Можете да използвате DMV или Query Store, за да получите информация за производителността на заявката, но информацията в двата източника е обобщена. DMV представляват среден CPU, I/O, продължителност и т.н. за заявка само докато е в кеша. Магазинът на заявки също предоставя средни показатели за множество ресурси, но се обобщава за определен период от време (например 30 минути или един час). Разбира се, има решения за наблюдение на трети страни, които са повече от способни да ви дадат всичко това и повече (като SentryOne), но за тази публикация исках да се съсредоточа върху собствените инструменти.
Ако искате да разберете ефективността на заявката за отделни изпълнения, за да определите точната заявка или набор от заявки, които може да са проблем, най-лесният вариант е да използвате разширени събития. И един от най-бързите начини да започнете е да използвате XEvent Profiler, който е достъпен чрез SQL Server Management Studio (започвайки от версия 17.3):
XEvent Profiler в SSMS
Основна употреба
Има две опции за XEvent Profiler:Standard и TSQL. За да използвате някоя от тях, просто щракнете двукратно върху името. Зад кулисите се създава вътрешно дефинирана сесия на събитие (ако вече не съществува) и се стартира и Live Data Viewer веднага се отваря с фокус. Обърнете внимание, че след като стартирате сесията, тя също ще се появи под Управление | Разширени събития | Сесии. Ако приемем, че имате активност срещу сървъра, трябва да започнете да показвате записи във визуализатора след пет секунди или по-малко.
Live Data Viewer (след двукратно щракване, за да стартирате стандартна сесия)
Стандартните и TSQL сесиите споделят някои събития, като Standard има повече общо. Ето списък на събитията за всяко:
Standard TSQL
sql_batch_starting sql_batch_starting
sql_batch_completed
rpc_starting
rpc_completed
logout logout
login login
existing_connection existing_connection
attention Ако искате да разберете информация за изпълнението на заявката, като например колко време е отнело изпълнението на заявката или колко I/O е изразходвала, тогава Standard е по-добра опция поради двете завършени събития. И за двете сесии единственият филтър е изключването на системни заявки за пакетни, rpc и събития за внимание.
Преглед и запис на данни
Ако стартираме стандартната сесия и изпълним някои заявки, във визуализатора виждаме събитието, текста на заявката и друга полезна информация като cpu_time, logical_reads и продължителност. Едно от предимствата на използването на rpc_completed и sql_batch_completed е, че се показва входният параметър. В случай, когато има съхранена процедура, която има големи вариации в производителността, улавянето на входния параметър може да бъде изключително полезно, тъй като можем да съпоставим изпълнение, което отнема повече време, с конкретна стойност, предадена на съхранената процедура. За да намерим такъв параметър, трябва да сортираме данните въз основа на продължителност, което не можем да направим, когато подаването на данни е активно. За да извършите какъвто и да е вид анализ, подаването на данни трябва да бъде спряно.
Спиране на потока от данни в Live Viewer
Сега, когато моите заявки вече не се въртят в размазване, мога да щракна върху колоната за продължителност, за да сортирам събитията си. Първият път, когато щракна върху него, ще се сортира във възходящ ред и тъй като съм мързелив и не искам да превъртя дъното, ще щракна отново, за да сортирам в низходящ ред.
Събития, сортирани по низходяща продължителност
Сега мога да видя всички събития, които съм заснел в ред от най-голяма продължителност към най-ниска. Ако търся конкретна съхранена процедура, която е бавна, бих могъл или да превъртя надолу, докато я намеря (което може да е болезнено), или да групирам или филтрирам данните. Тук групирането е по-лесно, защото знам името на съхранената процедура.
Името на обекта се показва в горната част на визуализатора, но щракването върху което и да е събитие rpc_completed показва всички елементи, заснети в панела с подробности. Щракнете с десния бутон върху object_name, което ще го маркира, и изберете Показване на колона в таблица.
Добавяне на име_обект към инструмента за преглед на данни
В горния панел вече мога да щракна с десния бутон върху object_name и да избера Group by this Column. Ако разширя събитията под usp_GetPersonInfo и след това сортирам отново по продължителност, сега виждам, че изпълнението с PersonID=3133 е имало най-голяма продължителност.
Събития, групирани по object_name, usp_GetPersonInfo, сортирани по низходяща продължителност
За да филтрирате данните:Използвайте или бутона Филтри…, опцията от менюто (Разширени събития | Филтри…), или CTRL + R, за да изведете прозорец за намаляване на набора от резултати въз основа на различните показани полета. В този случай филтрирахме по object_name =usp_GetPersonInfo, но можете също да филтрирате по полета като server_principal_name или client_app_name, тъй като те бяха събрани.
Струва си да се отбележи, че нито стандартната, нито TSQL сесията се записват във файл. Всъщност няма цел за нито една сесия на събитието (ако не сте знаели, че можете да създадете сесия на събитие без цел, сега знаете). Ако искате да запазите тези данни за по-нататъшен анализ, трябва да направите едно от следните неща:
- Спрете подаването на данни и запазете изхода във файл чрез менюто Разширени събития (Експортиране в | XEL файл…)
- Спрете подаването на данни и запишете изхода в таблица в база данни чрез менюто Разширени събития (Експортиране в | Таблица…)
- Променете сесията на събитието и добавете event_file като цел.
Вариант 1 е моята препоръка, тъй като създава файл на диск, който можете да споделите с други и да прегледате по-късно в Management Studio за допълнителен анализ. В рамките на Management Studio имате възможност да филтрирате данни, които не са подходящи, да сортирате по една или повече колони, да групирате данните и да извършвате изчисления (например средни стойности). Можете да направите това, ако данните са таблица, но трябва да напишете TSQL; анализирането на данните в потребителския интерфейс е по-лесно и по-бързо.
Промяна на сесиите на XEvent Profiler
Можете да промените стандартните и TSQL сесиите за събития и промените, които правите, ще се запазят чрез рестартиране на екземпляра. Въпреки това, ако сесиите на събитията бъдат прекратени (след като сте направили промени), те ще се върнат обратно към стойностите по подразбиране. Ако установите, че непрекъснато правите едни и същи промени, предлагам да напишете промените и да създадете нова сесия за събитие, която също ще продължи при рестартиране. Като пример, ако погледнем изхода, заснет досега, можем да видим, че както adhoc заявките, така и съхранените процедури са изпълнени. И макар че е чудесно, че мога да видя различните входни параметри за съхранените процедури, не виждам отделните оператори, които се изпълняват с този набор от събития. За да получа тази информация, ще трябва да добавя събитието sp_statement_completed.
Разберете, че както стандартните, така и TSQL сесиите за събития са проектирани да бъдат леки. Събитията statement_completed ще се задействат по-често от пакетните и rpc събитията, така че може да има повече излишни разходи, когато тези събития са част от сесия на събитие. Когато използвам събития с изявления, аз много препоръчват включването на допълнителни предикати. Като напомняне, rpc и пакетните събития само филтрират системни заявки – няма друг предикат. Като цяло препоръчвам и допълнителни предикати за тези събития, особено за натоварване с голям обем.
Ако се притеснявате дали стартирането на стандартната или TSQL сесиите ще доведе до спад в производителността на вашата система, разберете, че Live Data Viewer ще прекъсне връзката, ако създава твърде много излишни разходи за системата. Това е голяма безопасност, но все пак ще бъда внимателен, когато използвам тези сесии за събития. Вярвам, че те са фантастична първа стъпка за отстраняване на неизправности, особено за тези, които са нови в SQL Server или разширени събития. Ако обаче имате отворен Live Data Viewer и се отдалечите от машината си, сесията на събитието продължава да се изпълнява . Спирането или затварянето на Live Data Viewer ще спре сесията на събитието, което препоръчвам, когато приключите със събирането на данни или отстраняването на неизправности.
За сесии на събития, които искате да изпълнявате за по-дълъг период от време, създайте отделни сесии на събития, които записват към целевия event_file и имат подходящи предикати. Ако имате нужда от повече информация как да започнете с Extended Events, вижте сесията, която дадох в SQLBits миналата година относно мигрирането от Profiler към Extended Events.
